RE: Comments on draft-carroll-dynmobileip-cdma-04.txt

["Nelson, David" <dnelson@enterasys.com>]

Frank Quick writes...

> My last mail didn't address Nelson's modifications.  Perhaps:

<snip>

> (2) It is a normative requirement of RFC 2865 that receipt 
> of an Access-Reject at the NAS terminate the session of the
> attached network host.  This document is not consistent with 
> that requirement.

Hmmm... "violates" vs. "is not consistent with" sounds like spin to me.
I'd prefer my original wording.  I think it's entirely accurate, if
perhaps more blunt.

> As a result, the use of this specification in other circumstances
> than those described in the document is not recommended.  Any future
> work based on this specification should take these issues into
> consideration.

So are you suggesting that future work ought to be based on this
document?

I'm not looking to unreasonably bash this work, given that the errors
were very likely based on a lack of detailed understanding of RADIUS and
a lack of timely review by subject matter experts.  Still, I think in
the interests of "truth in advertising", we need to consider the
disputed RADIUS usages as being deprecated.
 
> The security comments address security concerns that are general, not
> associated with any identified normative requirement.  I think the
draft
> makes it clear enough that DMU in its present form is applicable only
to
> the cellular environment.  However, I might suggest adding something
in
> the security section, perhaps a new section following the current 7.7:
> 
> 7.8 Other False MN
> 
>      The security considerations of this specification rely, 
>      in part, on cellular MN authentication and other security 
>      features, and the protocol extensions as described herein 
>      potentially exhibit inadequate security properties when used
>      outside of the cellular environment.  As a result, the use of
>      this specification in other circumstances than those described
>      in this document may require modification of the protocol to 
>      provide a similar level of security.

If the authors would like to submit a revised draft including this text,
I think it would sufficiently address the security considerations issue.
I had not suggested a draft revision, because at this point in the
review cycle we were being asked to craft an IESG "disclaimer note", and
I had assumed that draft revisions were out of scope.




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>