[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