Subject: Re: [MOBILE-IP] Latest Challenge draft issued

From: Patrice Calhoun <[email-masked]>
Date: Fri, 22 Oct 1999 09:21:52 -0700

Just to reinforce my previous message, this is the wrong mailing list to have
such a discussion. However, my comments are below.

PatC
>Pat-
>
>I dont completely agree with some of the statements you make here at the
>end, so:
>
><snip>
>
>> >> >Why should this be sent to the Home Agent and not to the verification
>> >> >infrastructure.
>> >>
>> >> Because the ROAMOPS WG has deemed RADIUS inappropriate for roaming
>> >enviromnents.
>> >> Why should we, the Mobile IP WG, state that it is ok to make use of
>> >> RADIUS?
>
>Ill review the discussion in ROAMOPS again, but I dont remember this
>being in their last charter. They were developing the drafts for the phone
>book, and requesting AAA determine a protocol, and then they were
>"disbanded" by the IESG.

hmmm... well not exactly. We were done putting together our requirements, and
decided to start protocol design because the AAA WG was not planning on having
anything done in a "reasonable" timeframe. The IESG took this message in hand,
decided to refocus the AAA WG to have something MUCH sooner (hence new charter),
and since roamops WAS done, we were shutdown. I suppose this means that
roamops' goal will be met. It really doesn't make sense for a WG to create
a protocol, when another WG is doing the same, does it?

>
>In fact, we have a RADIUS server that runs very well in proxy environments,
>and is doing so in several major ISP networks, especially in the area of
>wholesale dial. Performance and reliability are not even an issue with this
>implementation. RADIUS tends to leave a lot to the implementation: 1) that
>is not necessarily bad, it leaves the vendors room to meet their customers
>needs, and 2) that can be corrected via new standards.

Interesting view. I, for one, disagree with you here. I have spent LOTS of
time on:

Command> set radius_mode [cisco, 3com, ascend, ascend_newer, acc, msft, ...]

The IETF normally tries to create standards that promote interoperability. I
think that the above clearly shows that when everyone implements something
in a different method, then the IETF has failed.

As for your (2) above, I have just recently looked at the RADIUS v2 draft,
btw it is NOT a second version of the protocol, but rather some clarifications
to the draft to move it from proposed to draft standard. However, the draft
now includes LOTS of new protocol changes that are NOT allowed between
proposed to draft, AND many of these have never been run on the Internet, and
as far as I know, have no interoperability testing done. I suspect strongly
that the IESG will not let most of these changes through, without moving the
document back to proposed standard.

That said, most of these changes do not really fix the known RADIUS problems.

>
>As for the other question, neither ROAMOPS or Mobile IP should
>care, at this point, what the exact protocol is. Requirements need to
>be made, and discussed on their individual merits. In the end, the AAA
>list will have a comprehensive list of AAA requirements for a new
>protocol. (Which I believe they have just announced - great job all).
>
>At that point, drafts can be submitted (RADIUS v2, DIAMETER,
>or something else), and the AAA team can determine the appropriate
>standard based on all of the AAA requirements. It seems unfair to drive
>the requirements discussion towards your bias (DIAMETER) or mine
>(RADIUS).
True. Putting the fact that I may have some protocol biases, my goal is to
make use of the protocol developed by the AAA WG.

>
>The discussion should center on requirements - irregardless of
>an existing protocol. If we want to add current installation needs,
>it would have to include RADIUS, as not enough major vendors
>are supporting (or have been given the business case - customer
>req for) DIAMETER. Yes there may be limitations, but the business world
>will not wait for a brand new protocol, they will start with some base
>line. (I know this is covered in the backwards compatibility req's).

As I specified in my previous e-mail, the draft does not forbid the FA from
talking to a local RADIUS server.

>
>> >To   my knowledge  only  protocol  RFC2607    talks  about  in roaming
>> >envoirnments is RADIUS.  The problems are   also very bussniess  model
>> >dependent.
>>
>> Yes, RFC2607 describes roaming using RADIUS, and section 7 specifically
>> talks about its weaknesses. RFC 2477 was put together with the intent to
>> start evaluating new protocols against the requirements.
>>
>> If you like, please take this up on the roamops list, not here.
>>
>> >
>> >
>> >
>> >> Note that I was talked down to a SHOULD from a MUST, so if you want to
>run
>> >> RADIUS in a roaming environment, then the draft DOES allow it.
>> >
>> >
>> >RADIUS is being used in Proxy environemnts currently. For roaming and
>> >wholesale dial.
>> >
>> >Please see
>> >http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-01.tx
>> >which is clarifications to RFC2138 for use of RADIUS in Proxy
>> >environments.
>>
>> Sorry, but the list of changes to the protocol DO NOT meet RFC 2477
>> requirements. Please take this up on the lists where people are active
>> in this space as opposed to Mobile-IP. A good one, again, is roamops.
>>
>> >
>> >I don't see why Mobile IP WG should limit the use of RADIUS.
>>
>> I'd like to understand better your insistence on using RADIUS to address
>> this problem when a working group has deemed that it is insufficient, and
>> a new WG has been setup to address the problem.
>
>It is a bit silly to say this discussion should be brought up in the ROAMOPS
>list, as they have no charter to discuss this issue currently (or any other,
>now
>that they are done). Additionally, some of the questions come up based on
>the roaming/proxy possibilities in a Mobile-IP or wireless environment.
>
>The frustration, as I have watched some of the discussion, is being told
>DIAMETER is the answer, when not all of the questions have been asked.
>As I said, we should come up with requirements based on individual merit,
>not what we want final implementations to be (pointing fingers at all biases
>equally).

hmmm... this is not a requirements document. Charlie and I agreed to add a
new authentication extension into the document. I WILL NOT start to address
RADIUS roaming in the draft. If that does happen, then so be it. It is outside
the scope of the document.

As for your question/answer statement, I am pretty sure that we DO know the
questions. I think that I may have an answer, and you may have a different
answer. How about we take the *AAA requirements* and work with that. There
is NO reason to start a AAA requirements / roaming requirements thread in
this list. roaming requirements belong in roamops, not here.

PatC

---

From: Gopal Dommety <[email-masked]>
Date: Fri, 22 Oct 1999 09:47:43 -0700

Pat,

See below.

> such a discussion. However, my comments are below.

The reason we are having this discussion here is because this
discussion is relevant to the draft and its wording (see below) and
you were referring to the work of ROAMOPS.

> document back to proposed standard.

It went through last call, so I guess the working group is okay with
it.

> talking to a local RADIUS server.

Then why does  the text say "If the  MN-RADIUS  extension (see Section
4.3) is present, the foreign   agent SHOULD forward the request to the Home Agent" and "If the MN-AAA Authentication extension (see Section 4.2) is present
   in the message, or if an NAI extension is included indicating that
   the mobile node belongs to a different administrative domain, the
   foreign agent may take actions outside the scope of this protocol
   specification to carry out the authentication of the mobile node ".

Thanks
Gopal