Re: [Mip4] AD review of draft-ietf-mip4-generic-notification-message

Was there any response on this? I'd like to get a new draft version for 
the small modifications below, and ship the document.

Jari

Jari Arkko wrote:
> I have reviewed this document. It was generally well written, though a 
> bit tiresome to read given the many slightly different behaviours 
> between messages sent from HA/FA/MN to HA/FA/MN.
>
> I did not see any major problems, but there were a few editorial 
> issues, and a few errors or inconsistencies. My main worries were:
>
> 1. The inconsistency of the rules regarding A flag and code 0.
>
> 2. The inconsistency and accuracy of the text that specifies how the 
> FA deals with failed HA-FA AEs.
>
> 3. The rules on how the HA decides whether it is seeing a message from 
> the FA or MN directly.
>
> Please address these issues and issue a new draft (I can ask the 
> secretariat to allow posting or if that turns out to not be possible, 
> I can register some OLD/NEW edits in the tracker).
>
> Detailed comments:
>
>> The value 0 is reserved and SHOULD not be used.
>
> s/SHOULD not/SHOULD NOT/ (2 instances)
>
>> [RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for 
>> Carrying Network Access Identifiers", RFC 3846, June 2004.
>
> This is an unnecessary reference. Please remove and/or justify.
>
>> This document mandate the MN-HA AE when this message is sent
>
> Instead: This document mandates the MN-HA Authentication Extension 
> (AE) when this message is sent
>
>> Source Port Copied from the source port of the
>> corresponding GNM.
>
> Shouldn't this be:
>
> Source Port Copied from the destination port of the
> corresponding GNM.
>
>> If the "A" flag is set in the GNM, then the MN MUST send the 
>> acknowledgement with Code 0.
>
> I understand that the acknowledgement must be sent. But why is there a 
> requirement that the code must be set to 0 in this case? It does not 
> seem to make make sense, but maybe I'm missing something. In any case, 
> Section 4.3.2 already says: "The Code field of the GNAM is chosen in 
> accordance with the rules specified in the section 4.2. When replying 
> to an accepted notification, a MN SHOULD respond with Code 0." I think 
> this is sufficient, and I would suggest deleting the "with Code 0" 
> part from above.
>
>> if the "MD" value is set to 0, the FA MAY validate the FA-HA AE if 
>> present. if the FA-HA AE is invalid, all non-authentication
>> extensions between HA and FA MUST be removed, FA SHOULD relay the GNM
>> to the MN's home address as specified in the Home Address field of
>> the GNM, MN will eventually validate the MN-HA AE to ensure that all
>> information sent to the MN is integrity protected. if the FA-HA AE is
>> valid, FA MUST relay the GNM to the MN's home address as specified in
>> the Home Address field of the GNM. 
> s/if/If/
>
> Also, I do not understand the part about removing non-authentication 
> extensions. Did you mean all extensions specified to be for HA-FA 
> only? Or all extensions, period? Why would anything be forwarded if 
> the HA-FA authentication is present but fails? What would be the use 
> of the notification if all non-authentication data was stripped but it 
> still ended up in the MN? I would suggest reformulating this as follows:
>
> OLD:
> all non-authentication extensions between HA and FA MUST be removed,
> NEW:
> all extensions between the HA-MN AE and the HA-FA AE MUST be removed,
>
> But maybe I am missing something. How are HA-FA AEs handled in other 
> specifications?
>
>> The FA MUST check that the Identfication field is correct using the
>
> s/Identfication/Identification/
>
>
>> if the "MD" value is set to 2, the FA MAY check the MN-FA AE and
>> Authenticator value in the Extension. if the MN-FA AE is invalid, all
>> non-authentication extensions between MN and FA MUST be removed, FA
>> SHOULD relay the GNM to the HA's address as specified in the Home
>> Agent Address field of the GNM, HA will eventually validate the MN-HA
>> AE to ensure that all information sent to the HA is integrity
>> protected. if the FA-HA AE is valid, FA MUST relay the GNM to the
>> HA's address as specified in the Home Agent Address field of the GNM.
>> The FA MUST NOT modify any of the fields beginning with the fixed
>> portion of the GNM through the MN-HA AE or other authentication
>> extension supplied by the MN as an authorization-enabling extension
>> for the HA.
>
> Same issues as above with MD 0. s/if/If/ and
>
> OLD:
> if the MN-FA AE is invalid, all non-authentication extensions between 
> MN and FA MUST be removed
> NEW:
> If the MN-FA AE is invalid, all extensions between the MN-HA AE and 
> the MN-FA AE MUST be removed
>
>> In the case of a FA-CoA and if the "MD" value is set to 2, if the FA
>> received this message, the MN-FA AE MUST be checked, and the FA MUST
>> check the Authenticator value in the Extension. If no MN-FA AE is
>> found, or if more than one MN-FA AE is found, or if the Authenticator
>> is invalid, the FA MUST silently discard the GNAM message. If FA
>> accepted the MN's GNAM message, it MUST relay this message to the HA.
>> The FA MUST NOT modify any of the fields beginning with the fixed
>> portion of the GNAM message through the including the MN-HA AE or
>> other authentication extension supplied by the HA as an
>> authorization-enabling extension for the MN. 
>
> Isn't the treatment of relayed notification messages and 
> acknowledgments is different between 4.4.1 and 4.4.4? In 4.4.1, the 
> conditions about MN-FA AE are different, and it talks about removing 
> extensions. But here the entire message is discarded. Is this correct?
>
>> If the "MD" value is set to 2, MN-HA AE MUST be checked, and the HA
>> MUST check the Authenticator value in the Extension. If no MN-HA AE
>> is found, or if more than one MN-HA AE is found, or if the
>> Authenticator is invalid, the HA MUST silently discard the GNAM. If
>> the HA accepted this message, the HA MAY also process it based on the
>> notification event.
>>
>> In the case of a Co-located CoA, if the HA received this message, the
>> MN-HA AE MUST be checked, and the HA MUST check the Authenticator
>> value in the Extension. If no MN-HA AE is found, or if more than one
>> MN-HA AE is found, or if the Authenticator is invalid, the HA MUST
>> silently discard the GNAM message.
>
> This is from Section 4.5.2. Perhaps my eyes are tired, but I cannot 
> see the difference between the two paragraphs. Shouldn't the latter 
> paragraph talk about FA-HA AEs?
>
>> The HA MUST check that the Identfication field is correct using the
>
> Typo
>
>> if the the "MD" value is set to 2, this message come from MN, if
>> FA-HA AE is presented, it MUST be checked, and the HA MUST check the
>> Authenticator value in the Extension.
>
> s/if/If/
>
> Also, this text from Section 4.5.3 seems different from the text in 
> Section 4.5.2. In this text we look a the presence of the FA-HA AE, 
> and in the former we just check if co-located CoAs are in use. 
> Shouldn't the HA always determine if co-located mode is in use, and if 
> it is, require FA-HA AE?
>
>> An example would be "Maintenance Stopping", "Prepaid Expire". These 
>> string MUST be strictly defined so they could be easily understood by 
>> all of the network entities. "Subtype" number would need to be 
>> decided by the working group.
>
> I would rephrase this slightly:
>
> An example would be "Maintenance Downtime", "Prepaid
> Expiration". Such strings would have to standardized so that
> can be understood by all network entities, and a
>
> These string MUST be strictly defined so they could be easily 
> understood by all of the network entities, and a suitable GNM Subtype 
> number would have to be allocated. All such definitions are left for 
> future specifications.
>
>> This documents require that all MNs, FAs and HAs MUST implement 
>> timestamp- based replay protection.
>
> This document...
>
> Jari
>
> -- 
> Mip4 mailing list: Mip4@ietf.org
> Web interface: https://www.ietf.org/mailman/listinfo/mip4
> Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>
>