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

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

(Resent from the correct source address; apologies for possible duplicates)

 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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 19 Feb 2009 00:57:27 -0800 (PST)

Hi Jari,

Our responses inline.

> These encapsulation modes do not correspond to the ones listed in

This is an error, will fix it.

>
>>  structure maintained by the local mobility anchor [RFC-5213
>>  <http://tools.ietf.org/html/rfc5213>] MUST be

Sure

> option, right? Please clarify, I thought at first that you asked to send

Yes, this is the data strucutre and the source. Will rephrase this.

>>        the mobile access gateway is not behind a NAT [RFC-3022
>>        <http://tools.ietf.org/html/rfc3022>], this

Yes. I dont see this yet in -07 version of the DSMIP spec. If that
will be fixed there, we can point to that doc. But, for completeness
we may have to still list it here ?

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

Its a simple address comparision of the source and CoA. But, we
can point to the section in DSMIP. But, I'm afraid because of the
difference in the solution scope, network-based vs client-based
mobility, difference in terminology, an implementor who is not
exposed to this history, may be thoroughly confused, if we point
him back and forth between these two specs, as you have raised
the concern below. This will be addressed as part of the general
comment on DSMIP/PMIP-IPv4 dependancy.

>>    *  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
>>     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>.
>> 
>

Ok.

> about what encapsulation mode to use).

Sure

> the fourth clause needs to move earlier, too.

sure, thanks

> should the rule have appeared somewhere else?

Final consideration after processing the packet, to send a PBA with
status code 0. It should be here, but will structure it better.

> Again, which parts of this are in dsmip?

Will address this as part of the general comment on
DSMIP/IPv4-PMIP depandancy

> elsewhere in the IP layer.

Will address as part of the general comment on DSMIP/IPv4-PMIP
doc dependancy

> about the initial PBU either. Is there some new requirement here beyond

This is per 5213, no new requirement. We wanted some consistency between
the initial/rereg/dereg messages.

>>     message) MUST be protected using IPsec ESP [RFC-4301
>>     <http://tools.ietf.org/html/rfc4301>] mode and

Agree, this is wrong. Earlier, we were allowing both approaches of
protection, Security association using IPv4 addresses or IPv6 addresses.
When using IPv4 transport, we allowed the ESP to be keyed using IPv4
addresses and for that we had to require global addresses. Now, we
just allow single mode, which is protecting the IPv6 packet with ESP,
with the SA keyed to the IPv6 addresses of the LMA and MAG. This will
be fixed.

> need to support all options; maybe the IPv6 part is actually enough.

If we go with the approach of establishing SA's using IPv6 addresses,
our outer header is a mere transport. Once the decap of IPv4 header is
performed and the inner IPv6 PBB/PBA packet is re-routed, the PAD/SPD
rules from Section 4, RFC 5213 should work ? Any ways, we require
configured globally unique IPv6 addresses on both LMA and MAG. Will
a reference to 5213 be sufficient ?

> keywords ... In addition, the node MUST check ...

We did have this concern that we have created this unnecessary
dependency or reference to DSMIP. We are mainly using the
following from DSMIP

- DSMIP port
- IPv4 Home Address option
- IPv4 Address Ack option
- NAT detection rule of a single string compare check.
- Conceptual data structure extension for adding these elements

Currently, the draft in every other line, we are pointing to DSMIP,
that is bad. If we can only borrow the options and the port number,
with no dependency on the processing logic, it will really help.
Clearly, this is not duplication of functionality. There is not
much to state on NAT detection or for other simple check. For
completeness and for the fact that the core functional elements are
made to appear different by choice of different names, it might be
better  to keep those 10 lines of text in both places and not have
references. This approach will help the reader and save them from
reading  two different specs, written for two mobility models.
Else, I'm afraid the reader will be tossed between these two specs,
possibly he will never finish both :)

Sri

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Feb 2009 11:04:40 +0200

Sri,

> possibly he will never finish both :)

No, it is not appropriate to use DSMIP as just a definition of some 
option formats and then supply alternate/duplicate semantics for them. I 
did not actually see any specific case where your behaviour rules would 
have differed from DSMIP. I do think that you have to rely on DSMIP for 
everything that is defined there, including NAT detection and so on. And 
then, you have to point out very explicitly all additional requirements 
or changes, if any.

Of course, there are many different ways of editorially expressing these 
things. But I believe your spec will be crisper and shorter if you 
remove the parts that are already dealt with in DSMIP.

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 19 Feb 2009 01:21:15 -0800 (PST)

Hi Jari,

On Thu, 19 Feb 2009, Jari Arkko wrote:

> No, it is not appropriate to use DSMIP as just a definition of some option 
> formats and then supply alternate/duplicate semantics for them. I did not 
> actually see any specific case where your behaviour rules would have differed 
> from DSMIP. I do think that you have to rely on DSMIP for everything that is 
> defined there, including NAT detection and so on. And then, you have to point 
> out very explicitly all additional requirements or changes, if any.
>
> things. But I believe your spec will be crisper and shorter if you remove the 
> parts that are already dealt with in DSMIP.

The rules when processing a BU vs PBU, or BA vs PBA, the minor semantics
associated with certain options and when coupled with the terminology,
I really hope, one can follow all the rules from both the specs.

So, from your review, we have duplicated certain aspects related to
conceptual data structure elements, the rule on NAT detect, we can
remove them and point to DSMIP. But, these conceptual elements may have
to be added to DSMIP spec. We can take them out and create a reference.

Regards
Sri