Subject: [Mip4] draft-ietf-mip4-rfc3012bis-04.txt review

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Aug 2005 11:23:42 +0300

I understand that this draft is mainly a bug fix revision.
It seems reasonable, overall. Some small technical issues/
questions, clarifications, and nits below, however:

Technical:

> 3.5  Mobile Node Processing for Registration Replies
>
>    ...
>
>    UNKNOWN_CHALLENGE: ... MUST use a new Challenge value in
>    any new registration, obtained either from an Agent Advertisement, or
>    from a Challenge extension to the Registration Reply containing the
>    error.
>
>    MISSING_CHALLENGE: ... 
>    SHOULD send a Challenge extension containing an unused challenge in
>    the next Registration Request.
>
>    BAD_AUTHENTICATION: ...  MUST use a new Challenge
>    value in any new registration, obtained either from an Agent
>    Advertisement, or from a Challenge extension to the Registration
>    Reply containing the error.
>
>    FA_BAD_AAA_AUTH: ...  MUST use a new Challenge value
>    in any new registration, obtained either from an Agent Advertisement,
>    or from a Challenge extension to the Registration Reply containing
>    the error.
>
>    HA_BAD_AAA_AUTH: ... MUST use a new Challenge value
>    in any new registration, obtained either from an Agent Advertisement,
>    or from a Challenge extension to the Registration Reply containing
>    the error.
>
>    STALE_CHALLENGE: ... MUST use a new Challenge value in
>    next Registration Request, obtained either from an Agent
>    Advertisement, or from a Challenge extension to the Registration
>    Reply containing the error.
>
>    HA_WRONG_CHALLENGE: ... (no mention of the challenges)...

The challenge rules are almost the same for all error cases,
except the last one. I realize that the last one is a serious
error, and there's little that the mobile node can do about
it. However, the rules appear to imply that a new challenge
value is required in all cases, except if you retry after
HA_WRONG_CHALLENGE. Is there a reason for this? Presumably
if you want to retry the registration just in case the system
now works correctly, you would want to use a new, fresh
Challenge.

If there is no reason for this difference, I would suggest
deleting some of the case-specific rules above and replacing
them with generic text at the bottom of the section, saying
something like:

  "In any case, if the mobile node attempts to register again
   after such an error, it MUST use a new Challenge value
   in such a registration, obtained either from an Agent Advertisement,
   or from a Challenge extension to the Registration Reply containing
   the error."

(And even this may be unnecessary, given that there is also a requirement
close to this in Section 4.)

> 11.  IANA Considerations
>
>    All protocol values in this specification are to be the same as
>    defined in RFC 3012 [RFC3012].  Additionaly, new error codes
>    FA_BAD_AAA_AUTH, HA_BAD_AAA_AUTH, and HA_WRONG_CHALLENGE are defined
>    by this document.  Among these, HA_WRONG_CHALLENGE may appear in the
>    Status code of the FA Error extension defined in [FAERR].

Are IANA considerations & rules needed for the Subtype field
and SPI 0-255 range defined in Section 5?

> The protocol messages for handling the authentication within the
>  verification infrastructure, and identity of the agent performing the
>  verification of the foreign agent challenge, are not specified in
>  this document, because those operations do not have to be performed
>  by any Mobile IP entity.

I'm not sure I understand the part that begins "identity of the agent".
Also, mobile IP entities appear to have to be involved, at least the FA
is involved. Of course there can be other intermediate nodes such
as AAA proxies or authentication servers that are not Mobile IP
entities.

The fact that you are not specifying the verification infrastructure
becomes clear already earlier in Appendix B, so one way to deal with
this paragraph is to remove it.

>       Preceding Mobile IP data || Type, Subtype, Length, SPI

"Preceding Mobile IP data" is not explained. All bytes preceding
the start of the option in question, presumably? But starting
from the IP, UDP, or Mobile IP header or something else?

Editorial:

>    defined in RFC 3012 [RFC3012].  Additionaly, new error codes

s/additionaly/additionally/

>    node has attempted to use.  The following stylized programmatic
>    algorithm accomplishes this objective.  The maximum amount of total

Maybe s/stylized programmatic algorithm/pseudo-code algorithm/

> Appendix A.  Change History

Might be an idea to clean this up to a "What's New vs. RFC3012"
section. Right now its hard to see if all the changes are true
technical changes from 3012, editorial modifications, or just
back-and-forth modifications between draft revisions.

Other editorial issues:

I spent quite a bit of time trying to understand all the "MUST
precede" rules relating to the order of the options (Sect 3, Sect
6, etc). Its still hard to get an overview, and its also hard to
convince yourself that the specification of these rules is
complete and unambiguous. But I don't have a good suggestion
for a better way to describe the rules.

>       Least-order 237 bytes from Challenge
>       ...
>    using MD5.  Finally, the least significant 237 bytes of the challenge

Would "last 237 bytes" be easier to understand?

--Jari

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/