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