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

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Sep 2005 01:54:22 +0300

Hi Jayshree,

>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.)
>
>[JB] Agree. Since the section is related to processing at the mobile
>node, I will go ahead and include generic text and remove corresponding
>text from each of those error definitions. 
>  
>
Ok.

>Are IANA considerations & rules needed for the Subtype field and SPI
>0-255 range defined in Section 5?
>
>[JB] As you know, the sub-type defined in section 5 is same as RFC3012
>and there was no change made in the format in this bis draft. In the
>IANA Considerations section, we have statement mentioning dependency on
>RFC3012. Do you think we still need to have rules defined in this
>document?
>  
>
Hmm. Good question, I didn't notice the reference.
Let see, I need to go and read RFC 3012 section
first...  OK, there's some more information about the rules
in there. Then the nature of your bis document is that it
obsoletes 3012... but you have the reference. I don't know.

The IANA rules serve really two purposes (1) a command to
IANA to allocate new numbers or name spaces and (2)
documenting the rules through which further allocations
should be made.

Its a judgement call what to do here. All the information is
there if you considered the reference, we're not really missing
anything. But given that your document obsoletes
3012, it might seem natural to copy the information
to the new document, as you presumably have done
for everything else as well. I'm not even sure if a normative
reference to an obsoleted document is possible in
a standards track spec, even if this is admittedly
a special case :-)

>>      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?
>
>[JB] Let me know if the following changes are acceptable for defining
>Preceding Mobile IP data.
>
>From:
>The default algorithm for computation of the authenticator is HMAC-
>Preceding Mobile IP data || Type, Subtype, Length, SPI
>where the Type, Length, Subtype, and SPI are as shown in Section 5.
>
>To:
>The default algorithm for computation of the authenticator is HMAC-
>Preceding Mobile IP data || Type, Subtype, Length, SPI
>where the Type, Length, Subtype, and SPI are as shown in Section 5. The
>Preceding Mobile IP data refers to the UDP payload (the Registration
>Request or Registration Reply data) and all prior Extensions in their
>entirety.
>  
>
Sounds good to me.

>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.
>
>[JB] Currently we have noted modifications between draft revisions. I
>don't have any issue summarizing just technical changes in short list if
>there are no further objections from the group.
>  
>
Ok.

>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.
>
>[JB] My suggestion is to keep the text as it is. 
>  
>
Ok.

--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/

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Wed, 14 Sep 2005 14:35:30 -0500

Hi Jari,

I will include most of your comments but need further
clarification/acceptance on some. Please see my response inline (marked
with [JB]).

Regards,
Jayshree

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jari Arkko
Sent: Tuesday, August 23, 2005 3:24 AM
To: Charlie P; [email-masked]
Subject: [Mip4] draft-ietf-mip4-rfc3012bis-04.txt review

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,
>    the error.
>    HA_BAD_AAA_AUTH: ... MUST use a new Challenge value
>    in any new registration, obtained either from an Agent
Advertisement,
>    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)...

> 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].

> 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.

[JB] Ok. I will remove the last statement of the paragraph ("because
those ...Mobile IP entity")

From:

To:

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

s/additionaly/additionally/
[JB] ok

>    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/
[JB] ok

> Appendix A.  Change History

Other editorial issues:

[JB] My suggestion is to keep the text as it is. In addition to that, I
can provide MN-AAA extension order wrt to MN-FA and MN-HA for the
registration request and registration reply if it is helpful. 

>       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?
[JB] ok

--Jari