[Mip4] AD review of draft-ietf-mip4-generic-notification-message
Jari Arkko <jari.arkko@piuha.net> Fri, 17 July 2009 16:08 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: mip4@core3.amsl.com
Delivered-To: mip4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 145F23A6E8C for <mip4@core3.amsl.com>; Fri, 17 Jul 2009 09:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level:
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywAxbzdbudOQ for <mip4@core3.amsl.com>; Fri, 17 Jul 2009 09:08:02 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 11B233A6C3B for <mip4@ietf.org>; Fri, 17 Jul 2009 09:07:59 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id C7DBB19878A; Fri, 17 Jul 2009 19:08:30 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 24EB219863D; Fri, 17 Jul 2009 19:08:30 +0300 (EEST)
Message-ID: <4A60A1FD.8000002@piuha.net>
Date: Fri, 17 Jul 2009 19:08:29 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Mobile IPv4 Mailing List <mip4@ietf.org>, draft-ietf-mip4-generic-notification-message@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: [Mip4] AD review of draft-ietf-mip4-generic-notification-message
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mip4>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2009 16:08:04 -0000
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