Subject: [netlmm] AD review of draft-ietf-netlmm-pmip6-ipv4-support (part 4)

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Feb 2009 00:00:23 +0200

From page 30 to 41:

> The supported encapsulation modes
>       for carrying mobile node's IPv4 or IPv6 packets when using IPv4
>       transport are as shown below.
>
>       *  IPv4 (IPv4 or IPv6 Payload packet carried in an IPv4 packet)
>
>       *  IPv4-UDP (Payload packet carried in an IPv4 packet with UDP
>          header).
>
>       *  IPv4-UDP-TLV (Payload packet carried in an IPv4 packet with UDP
>          and TLV header).  Refer to [ID-DSMIP6].
>
>       *  IPv4-UDP-ESP (Payload packet carried in an IPv4 packet with UDP
>          and ESP headers).  Refer to [RFC-3948].

These encapsulation modes do not correspond to the ones listed in 
Section 2.2.

> structure maintained by the local mobility anchor [RFC-5213 <http://tools.ietf.org/html/rfc5213>] MUST be
> extended with the following additional parameters.
>
> o  This is the IPv4 Proxy Care-of Address configured on the mobile
>   

s/This is the/The/

>    access gateway that sent the Proxy Binding Update message.  This
>    address can be obtained from the IPv4 Care-of Address option [ID-
>    DSMIP6], present in the received Proxy Binding Update message.
>    However, if the received Proxy Binding Update message is not sent
>    as an IPv4 packet, i.e., when using IPv6 transport, this field
>    MUST be set to ALL_ZERO value.
>   
"this field" refers to the data structure, NOT the IPv4 Care-of Address 
option, right? Please clarify, I thought at first that you asked to send 
zeros in the option.

>    o  The IPv4 NAT translated address of the mobile access gateway.  If
>       the mobile access gateway is not behind a NAT [RFC-3022 <http://tools.ietf.org/html/rfc3022>], this
>       address will be the same as the address configured on the egress
>       interface of the mobile access gateway.  This address can be
>       obtained from the IPv4 header of the received Proxy Binding Update
>       message.  However, if the received Proxy Binding Update message is
>       not sent as an IPv4 packet, this field MUST be set to ALL_ZERO
>       value.
>   

Wouldn't you need the UDP encapsulation port as well? And why aren't 
these datrastructures defined in the dsmip specification?

> 4.1.3.1 ...
>
>    o  ...
>    o  If there is an IPv4 Care-of Address option [ID-DSMIP6 <http://tools.ietf.org/html/draft-ietf-netlmm-pmip6-ipv4-support-09#ref-ID-DSMIP6>] present in
>       the request and if the outer encapsulation header is IPv4-UDP,
>       then the NAT presence detection procedure specified in Section
>       4.1.3.3 MUST be used for detecting the NAT in the path.
>   

Aren't these rules already in dsmip? This specification should not 
attempt to duplicate dsmip, it should reference it.

This comment applies also to the rest of Section 4.1.3.1, and probably 
elsewhere as well.

> *  If the received Proxy Binding Update message was sent with IPv4
>    encapsulated header, then the encapsulation mode for the bi-
>    directional tunnel MUST be set to IPv4.  Otherwise, the
>    following considerations apply.
>
> *  If NAT is detected on the path, or if the (F) flag in the
>    received Proxy Binding Update message is set to the value of 1,
>    then the encapsulation mode MUST be set to IPv4-UDP.  Otherwise
>    the encapsulation mode MUST be set to IPv4.
>   
> *  If NAT is not detected on the path and if the (F) flag in the
>    received Proxy Binding Update message is set to the value of 1,
>    but if the configuration flag,
>    AcceptForcedIPv4UDPEncapsulationRequest, is set to a value of
>    0, then the local mobility anchor MUST reject the request with
>    the Status field value set to 129 (Administratively
>    prohibited).
>   
> *  If the (T) flag [ID-DSMIP6 <http://tools.ietf.org/html/draft-ietf-netlmm-pmip6-ipv4-support-09#ref-ID-DSMIP6>] in the Proxy Binding Update message
>    is set to value of 1, then the encapsulation mode MUST be set
>    to IPv4-UDP-TLV.
>   
> o  The local mobility anchor MUST send the Proxy Binding
>    Acknowledgement message with the Status field value set to 0
>    (Proxy Binding Update Accepted).  The message MUST be constructed
>    as specified in Section 4.1.3.2 <http://tools.ietf.org/html/draft-ietf-netlmm-pmip6-ipv4-support-09#section-4.1.3.2>.
>   

"IPv4 encapsulated header" is not one of the encapsulation modes from 
Section 2.2.

Maybe this would be easier to read if the second and third clause 
swapped places (first check for errors and then make the conclusion 
about what encapsulation mode to use).

The currently second clause has an "otherwise" statement that seems to 
make the final conclusion about the encapsulation mode. Yet the fourth 
clause still specifies another special case encapsulation mode. Perhaps 
the fourth clause needs to move earlier, too.

The Status set to 0 rule at the end seems to be disconnected from the 
rest. Is there a "upon successful acceptance of the PBU" missing? Or 
should the rule have appeared somewhere else?

Not easy to read, and again I wonder if some of this is or should have 
been in dsmip.

> Section 4.1.3.2

Again, which parts of this are in dsmip?

Same for 4.1.3.3

>    To support the IPv4 Transport Support feature, the conceptual Binding
>    Update List entry data structure maintained by the mobile access
>    gateway [RFC-5213 <http://tools.ietf.org/html/rfc5213>] MUST be extended with the following additional
>    parameters.
>
>    o  The IPv4 address of the local mobility anchor.  ...
>
>    o  The IPv4 address of the mobile access gateway. ...
>   
The first one is OK, but the second one may not be. Nodes can already be 
assumed to know their own addresses; I do not think we need to create 
MIP-specific data structures to hold information that already exists 
elsewhere in the IP layer.

> o  When sending a Proxy Binding message for extending the lifetime of
>    a currently existing mobility session or for de-registering the
>    mobility session, the Proxy Binding Update message MUST be
>    constructed as the initial request.
>   
Why does this have to be stated? Nothing earlier in Section 4.2.2 talked 
about the initial PBU either. Is there some new requirement here beyond 
RFC 5213 or dsmip?

> o  If the mobile access gateway and the local mobility anchor are
>    using globally routable IPv4 addresses and if there is a security
>    associated that is based of IPv4 addresses, then the encapsulated
>    IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement
>    message) MUST be protected using IPsec ESP [RFC-4301 <http://tools.ietf.org/html/rfc4301>] mode and
>    additionally there is no need to apply ESP header on the IPv6
>    packet.  In all other cases, the Proxy Binding Update message MUST
>    be protected on the IPv6 packet of the Proxy Binding Update
>    message, prior to the IPv4 encapsulation.
>   
Why does globally routable IPv4 address matter for the purposes of this 
discussion? Presumably some operators will be running their networks in 
net10 space, and could conceivably run IPsec-based security for some of 
the signaling.

security associated?

Finally, I would expect that the IPsec SPDs determine what to protect 
and at what stage. Not the Mobile IP code. I would rely on the SPD, and 
for the IPv6 part that is already defined in existing RFCs. The only 
additional thing here is whether you can run IPsec on a different place 
in the header chain, right after the IPv4 packet instead. But to specify 
that I would expect to see recommendations on how to set up the 
policies. This may require some work, but I'm not actually sure that you 
need to support all options; maybe the IPv6 part is actually enough.

> Section 4.2

There's again a lot of material that is probably in dsmip. We need to 
talk about the specification style that is appropriate here. This draft 
has been written in a very precise, algorithmic manner (which I 
appreciate). However, it annoys the reader to have to wonder about the 
relationship between this text and what is in dsmip. If I have 
implemented dsmip, what new things do I have to do to implement this 
specification? Perhaps the following style might be useful if you want 
to both explain the details and specify the new requirements:

In order to perform X, the node follows the instructions from [dsmip] 
section such and such. ... some brief, informative explanation without 
keywords ... In addition, the node MUST check ...

Jari