Subject: Re: [MEXT] IPsec use in draft-ietf-mext-nemo-v4traversal-00

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 6 Feb 2008 20:56:02 +1000

Hi Pasi, 

Thanks for the comments. The comments in the other email will be handled in
the next rev.
Regarding these comments please see my response below. 

 > I do not think the spec is ready to be submitted to IESG without
 > non-trivial work on the IPsec aspects.
 > 
 > My main concerns are the following:
 > 
 > First, while the basic idea behind the DSMIPv6-IPsec interaction
 > seems doable, I am not convinced that an average implementor (i.e.,
 > someone who hasn't participated in writing this specification and
 > doesn't have a PhD) could actually figure out how it works based on
 > the current text. I would strongly suggest expanding the
 > description in Section 5.1, and including e.g. message diagrams
 > showing in what order the various local state updates and messages
 > have to happen. In the off-list discussions thinking how to
 > use IPsec, both Karen and I wrote such descriptions; merging
 > them (and updating the details to match the latest discussions)
 > could be a good starting point. I'm including my notes (which
 > may not be fully up-to-date) at the end of this message; feel
 > free to use them and/or Karen's text as starting points.

=> This is what I tried to do already. I haven't received comments from
Karen or Christian indicating dissatisfaction (not yet anyway). The issue
here is how much implementation detail should we include without crossing
the barrier from specification to implementation. As I mentioned in the
private discussions I'd like the reader to know *what* needs to be done, but
not necessarily *how* to do it. So, if you think the order of events is not
clear, please give me some specific changes to make it clearer. The issue of
message diagrams is not really the key point IMO, as I think any implementer
knows the messages exchanged. I believe what we want to show is what happens
when. 

 > 
 > Second, in places, the spec is close to the line drawn in water
 > between using IPsec and actually changing the IPsec architecture.
 > In particular, there are architectural details related to NATs that
 > AFAIK are not present in any other use of IPsec (including plain
 > Mobile IPv6). For example,
 > 
 > - On MN side, it's assumed that after IPsec processing, some
 > packets (in particular, BUs) are *not* processed as usual via IP
 > forwarding, but are rather handed back to "DSMIPv6" code for
 > special encapsulation. In other words, the treatment in IP
 > forwarding ("Forwarding" box in RFC 4301, Section 5.1) depends on
 > something else than the destination address, and more importantly,
 > on something that isn't visible in the packet itself (after it has
 > been encrypted) but is expected to survive IPsec processing.

=> MIPv6 does similar things architecturally anyway, like swapping the home
address with the content of the HAO. So, the idea of the packet returning to
the "calling function" to do things to it before sending is not new. 

 > 
 > - On HA side, it's assumed that IPsec processing doesn't just
 > decrypt the packet (and hand it over to IP forwarding), but also
 > somehow preserves DSMIPv6-specific information (in particular, 
 > the IP address/port in the outermost IPv4 header) across the
 > IPsec processing and eventually to the module processing BUs.

=> Correct. We could have avoided this using other alternatives but there
was no concensus. This is one of those issues that are implementation
dependent. Again the "calling function" could preserve this information
without relying on IPsec to do so. Hence, there is no need to change IPsec
architecture or implementation. When I worked on MIPv6 implementations it
was not difficult to pass additional information around with the packet. May
be things changed now :)

 > 
 > While these can certainly be implemented, they are architecturally
 > ugly, and may prevent using existing IPsec implementations as-is.
 > I'm not sure if we can avoid this (many other solutions for 
 > IPsec/DSMIPv6 integration were proposed and discussed, and none of
 > them was IMHO significantly better), but I believe the specification
 > should explicitly discuss these complications and their implications.

=> We can discuss the last complication above if you think it adds value to
the spec. As you said, this particular complication could have been avoided
with other alternatives but at a different cost/ugliness.

 > 
 > 
 > More detailed comments (which should be easier to fix than
 > the concerns above) follow:
 > 
 > 1) Section 5.1, "After the mobile node detects movement it
 > configures a new care-of address. In addition, the mobile node
 > updates its local Security Association information to include its
 > IPv4 address and the home agent's IPv4 address."
 > 
 > The security associations used for protecting BUs/BAcks are between
 > MN's IPv6 Home Address and HA's IPv6 address -- and those are
 > not updated. It may have to update the remote tunnel header
 > address for tunnel mode IPsec SAs, but according to the current
 > text, that should happen only after BAck has been received.
 > 
 > 2) Section 5.1, "The home agent may also need to change NAT
 > traversal fields in the IKE_SA." You can't figure out what this
 > means unless you participated in the related email discussions.
 > For HA, it probably means enabling "dynamic" update of address 
 > and port (in IKE_SA and tunnel mode IPsec SAs) based on incoming
 > authenticated packets (even if they're not BUs), as described in
 > RFC 4306 Section 2.23.

=> ok.

 > 
 > Text later actually requires the home agent to support this
 > feature; however, there should be some discussion about its
 > implications, as there are now *two* different ways how tunnel mode
 > SAs can get updated (this "dynamic update" and ordinary BUs).

=> What implications do you see? Apart from supporting two different
methods?

 > 
 > 3) The spec has to say something about using port 500 vs. port 4500
 > for IPsec traffic, since the text in RFC 4306 Section 2.23 won't
 > work as is (MOBIKE had to deal with this issue as well, see RFC
 > 4555 Section 3.3).
 > 
 > 4) Text has to mention that MN needs to enable/disable sending 
 > IPsec keep-alives (for port 4500) depending on whether it's behind
 > a NAT or not.

=> ok.

Hesham

 > 
 > Best regards, 
 > Pasi
 > 
 > ----------------------
 > 
 > What follows are my random notes about how this might work
 > (not necessarily fully up-to-date vs. rest of the spec):
 > 
 > NOTE: This description assumies two (conceptual) DSMIPv6
 > tunnels. One is used for sending BUs/BAcks (and always uses UDP
 > encapsulation); the other one is used for all other traffic.
 > During handovers these two tunnels are not updated at the same
 > time, and thus may temporarily use different IP addresses.  
 > They can also use different type of encapsulation.
 > 
 > 1. if in IPv4 network: update the "BU-DSMIPv6 tunnel" tunnel:
 >      local address = V4CoA:DSMIPv6-port
 >      remote address = V4HA:DSMIPv6-port
 > 
 > 2. if in IPv4 network: the MN deletes all route optimization 
 >    entries from its binding cache.
 >    
 > 3. The MN sends a Binding Update, which looks like this:
 > 
 >    if in IPv6 network:
 > 
 >    IPv6 header (src=V6CoA, dst=V6HA)
 >    Destination Options header
 >       Home Address option (V6HoA)
 >    ESP header (transport mode)
 >    Mobility header
 >       Binding Update
 >          Alternate Care-of Address option (V6CoA)
 >          [IPv4 Home Address option (V4HoA)]
 > 
 >    if in IPv4 network:
 > 
 >    the code sending the BU has to indicate that after IPsec
 >    processing, the packets has to be sent via "BU-DSMIPv6 tunnel"
 >    (and this indication has to survive IPsec processing).
 >  
 >    IPv4 header (src=V4CoA, dst=V4HA)
 >    UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
 >    IPv6 header (src=V6HoA, dst=V6HA)
 >    ESP header (transport mode)
 >    Mobility header
 >       Binding Update
 >          IPv4 Care-of Address option (V4CoA)
 >          [IPv4 Home Address option (V4HoA)]
 > 
 > 4. The HA receives a Binding Update 
 > 
 >    In IPv4 case, its header may have been changed by NAT to:
 > 
 >    IPv4 header (src=NATTED_V4CoA, dst=V4HA)
 >    UDP header (src=NATTED_DSMIPv6-PORT, dst=DSMIPv6-PORT)
 >    IPv6 header (src=V6HoA, dst=V6HA)
 >    [...]
 > 
 > 5. After DSMIPv6 decapsulation (in case of IPv4) and IPsec  
 >    processing, the packet will look like this:
 > 
 >    if in IPv6 network:
 > 
 >    IPv6 header (src=V6CoA, dst=V6HA)
 >    Destination Options header
 >       Home Address option (V6HoA)
 >    Mobility header
 >       Binding Update
 >          Alternate Care-of Address option (V6CoA)
 >          [IPv4 Home Address option (V4HoA)]
 > 
 >    if in IPv4 network:
 > 
 >    IPv6 header (src=V6HoA, dst=V6HA)
 >    Mobility header
 >       Binding Update
 >          IPv4 Care-of Address option (V4CoA)
 >          [IPv4 Home Address option (V4HoA)]
 > 
 >    the DSMIPv6 decapsulation has to store NATTED_V4CoA and 
 >    NATTED_DSMIPv6-PORT and somehow pass it on (surviving
 >    IPsec processing).
 > 
 > 6. If IPv4: The HA determines whether UDP encapsulation is 
 >    used (if the MN requested it, or local policy requires it, 
 >    or NATTED_V4CoA and V4CoA do not match).
 > 
 > 7. The HA updates its local forwarding state:
 > 
 >    if IPv4:   
 >      update bindings/something so that traffic to V4HoA/V6HoA gets
 >      sent via "Normal-DSMIPv6 tunnel"
 >      update both the "Normal-DSMIPv6" and "BU-DSMIPv6" tunnels as
 > follows:
 >        local address = V4HA:DSMIPv6-PORT
 >        remote address = NATTED_V4CoA:NATTED-DSMIPv6-PORT
 >      update the "Normal-DSMIPv6" tunnel as follows:
 >        encapsulation = "IPvX-in-IPv4" / "UDP" / "TLV"
 >    else
 >      update bindings/something so that traffic to V4HoA/V6HoA gets
 >      tunneled as IPvX-in-IPv6 to V6CoA.
 > 
 > 8. If the "HA" will set the "K" bit, it updates the IKE_SA 
 > as follows:
 >    local address = V4HA/V6HA:4500
 >    remote address = NATTED_V4CoA/V6CoA:4500 
 >    NAT traversal (dynamic updates) = yes/no
 >    (NOTE: remote port number is wrong if doing NAT-T; this
 >    will be updated below)
 > 
 > 9. The HA updates its *tunnel* mode IPsec SAD entries with MN:
 >    local tunnel header address = V4HA/V6HA:4500
 >    remote tunnel header address = NATTED_V4CoA/V6CoA:4500
 >    UDP encapsulation = yes/no
 >    (NOTE: remote port number is wrong if doing NAT-T; this
 >    will be updated below)
 > 
 > 10. The HA may also need to update information in its SPD, so
 >    that any new SAs get created with these tunnel header addresses.
 >    (This depends a bit on how IKE determines the correct peer
 >    when SA creation is needed.)
 > 
 > 11. HA generates a Binding Acknowledgement.
 >    
 >    if in IPv6 network:
 > 
 >    IPv6 header (src=V6HA, dst=V6CoA)
 >       Routing header (type 2): V6HoA
 >    Mobility header
 >       Binding Acknowledgement
 >          [IPv4 Home Address option]
 >          [IPv4 Acknowledgement option]
 > 
 >    if in IPv4 network:
 > 
 >    the code sending the BAck has to indicate that after IPsec
 >    processing, the packets has to be sent via "BU-DSMIPv6 tunnel"
 >    (and this indication has to survive IPsec processing).
 > 
 >    IPv6 header (src=V6HA, dst=V6HoA)
 >    Mobility header
 >       Binding Acknowledgement
 >          [IPv4 Home Address option]
 >          [IPv4 Acknowledgement option]
 >          [NAT detection option]
 > 
 > 12. After IPsec processing and DSMIPv6 encapsulation, it will
 >    look as follows:
 > 
 >    if in IPv6 network:
 > 
 >    IPv6 header (src=V6HA, dst=V6CoA)
 >       Routing header (type 2): V6HoA
 >    ESP header (transport mode)
 >    Mobility header
 >       Binding Acknowledgement
 >          [IPv4 Home Address option]
 >          [IPv4 Acknowledgement option]
 > 
 >    if in IPv4 network:
 > 
 >    IPv4 header (src=V4HA, dst=NATTED_V4CoA)
 >    UDP header (src=DSMIPv6-PORT, dst=NATTED_DSMIPv6-PORT)
 >    IPv6 header (src=V6HA, dst=V6HoA)
 >    ESP header (transport mode)
 >    Mobility header
 >       Binding Acknowledgement
 >          [IPv4 Home Address option]
 >          [IPv4 Acknowledgement option]
 >          [NAT detection option]
 > 
 > 13. After receiving the BAck, the MN updates its "Normal-DSMIPv6" 
 >    tunnel as follows:
 > 
 >    if in IPv4 network:
 >      update bindings/something so that traffic from V4HoA/V6HoA gets
 >      sent via "Normal-DSMIPv6 tunnel"
 >      update the "Normal-DSMIPv6 tunnel as follows:
 >        local address = V4CoA:DSMIPv6-port
 >        remote address = V4HA:DSMIPv6-port
 >        encapsulation = "IPvX-in-IPv4" / "UDP" / "TLV"
 >    else 
 >      update bindings/something so that traffic from V4HoA/V6HoA
 >      gets sent as usual IPvX-in-IPv6 to home agent.
 > 
 > 14. The MN updates IKE/IPsec state as follows:
 > 
 >    if "K" bit not set: 
 >      negotiate a new IKE_SA and new IPsec SAs replace all the 
 >      existing IPsec SAs (both transport and tunnel mode), 
 >      and close the old IKE_SA.
 >    else if "K" bit set, and no MOBIKE:
 >      update the IKE_SA as follows:
 >        local address = V4CoA/V6CoA:4500
 >        remote address = V4HA/V6HA:4500
 >        NAT traversal (keepalives) = yes/no (depending on 
 > NAT.D. option)
 >      update *tunnel* mode IPsec SAD entries with HA as follows:
 >        local tunnel header address = V4CoA/V6CoA
 >        remote tunnel header address = V4HA/V6HA
 >        UDP encapsulation = yes/no (depending on NAT Detection option)
 >      send an empty informational message (note that this step must
 >      not be done before receiving the BAck)
 > 
 >      the MN may also need to update information in its SPD, so that
 >      any new SAs get created with these tunnel header addresses.
 >      (This depends a bit on how IKE determines the correct peer
 >      when SA creation is needed.)
 >    else (MOBIKE):
 >      update IKE_SA and tunnel mode SAs with MOBIKE
 > 
 > 15. If the MN sent an empty Informational request, the HA will  
 >    update its IKE_SA as follows:
 >    remote_address = NATTED_V4CoA:NATTED_PORT_4500
 >    
 >    and tunnel mode IPsec SAD entries as follows:
 >    remote_address = NATTED_V4CoA:NATTED_PORT_4500
 >  
 > 16. Finally, the MN can start doing something about route 
 > optimization:
 >    if in IPv4 network:
 >      MN sends Binding Updates to delete bindings with all 
 >      Correspondent Nodes that were using route optimization. 
 >    else:
 >      MN could send Binding Updates to update bindings with
 >      Corrrespondent Nodes for route optimization. 
 > 
 > 17. End?
 > 
 > _______________________________________________
 > MEXT mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mext
 > 

_______________________________________________
MEXT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext

---

From: <[email-masked]>
Date: Thu, 7 Feb 2008 12:11:56 +0200

Hesham Soliman wrote:

> Hi Pasi, 
> 
> Thanks for the comments. The comments in the other email will be
> handled in the next rev.  Regarding these comments please see my
> response below.
>
>  > I do not think the spec is ready to be submitted to IESG
>  > without non-trivial work on the IPsec aspects.
>  > 
>  > First, while the basic idea behind the DSMIPv6-IPsec
>  > interaction seems doable, I am not convinced that an average
>  > implementor (i.e., someone who hasn't participated in writing
>  > this specification and doesn't have a PhD) could actually
>  > figure out how it works based on the current text. I would
>  > strongly suggest expanding the description in Section 5.1, and
>  > including e.g. message diagrams showing in what order the
>  > various local state updates and messages have to happen. In the
>  > off-list discussions thinking how to use IPsec, both Karen and
>  > I wrote such descriptions; merging them (and updating the
>  > details to match the latest discussions) could be a good
>  > starting point. I'm including my notes (which may not be fully
>  > up-to-date) at the end of this message; feel free to use them
>  > and/or Karen's text as starting points.
> 
> => This is what I tried to do already. I haven't received comments
> from Karen or Christian indicating dissatisfaction (not yet
> anyway). The issue here is how much implementation detail should
> we include without crossing the barrier from specification to
> implementation. As I mentioned in the private discussions I'd like
> the reader to know *what* needs to be done, but not necessarily
> *how* to do it. So, if you think the order of events is not clear,
> please give me some specific changes to make it clearer. The issue
> of message diagrams is not really the key point IMO, as I think
> any implementer knows the messages exchanged. I believe what we
> want to show is what happens when.

The messages exchanged over the wire are obvious; the local state
updates needed when sending and receiving those messages are not.
(I think this was pretty much proved in the email discussions
earlier, when non-obvious bugs where found the descriptions even
after several iterations.)

The specific change I am proposing is text describing both the
exchanged messages *and* the local state updates in the *order* they
are required to happen. This would not constrain implementation, as
any implementation with the same externally visible effects would 
be OK. 

>  > between using IPsec and actually changing the IPsec
>  > architecture.  In particular, there are architectural details
>  > related to NATs that AFAIK are not present in any other use of
>  > IPsec (including plain Mobile IPv6). For example,
>  > 
>  > packets (in particular, BUs) are *not* processed as usual via
>  > IP forwarding, but are rather handed back to "DSMIPv6" code for
>  > forwarding ("Forwarding" box in RFC 4301, Section 5.1) depends
>  > on something else than the destination address, and more
>  > importantly, on something that isn't visible in the packet
>  > itself (after it has been encrypted) but is expected to survive
>  > IPsec processing.
> 
> => MIPv6 does similar things architecturally anyway, like swapping
> the home address with the content of the HAO. So, the idea of the
> packet returning to the "calling function" to do things to it
> before sending is not new.

I don't find this similar at all. In MIPv6, packets that have been
through IPsec processing are forwarded just like other packets,
based on information in the packet headers.

> => Correct. We could have avoided this using other alternatives
> but there was no concensus. This is one of those issues that are
> implementation dependent. Again the "calling function" could
> preserve this information without relying on IPsec to do
> so. Hence, there is no need to change IPsec architecture or
> implementation. When I worked on MIPv6 implementations it was not
> difficult to pass additional information around with the
> packet. May be things changed now :)

I was not arguing that this is untolerably bad, or that this cannot
be implemented. I was arguing that this is an architecturally
important topic which needs to be discussed in the document itself,
not just emails on the list.

<snip>

> => What implications do you see? Apart from supporting two different

It basically means that the DS-MIPv6 module may not actually know
where MN's packets get sent (i.e. what is effectively the MN's
care-of-address). I find this pretty important thing to mention, as
the reader might otherwise assume that (effectively) changing the
CoA requires BU messages.

Best reards,
Pasi

---

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 7 Feb 2008 21:55:50 +1000

I think I'm getting closer to understanding what you want changed. Some
comments below.

 > after several iterations.)

=> Sure.

 > any implementation with the same externally visible effects would 

=> To avoid multiple iterations of the text again, let me reword the above
to:
The text needs to discuss the events resulting from the message exchanges in
the order that they take place. Is this what you want? If so, I can
re-arrange the text to make it more orderly and I would appreciate it if
after that you can point out *exactly* the missing details.

 > based on information in the packet headers.

=> If we talk about forwarding then I don't think there is a change. I think
what you mean is that some packets will have an IPv4 source address that
does not match an existing tunnel. Correct me if I misunderstood you, but
this is addressed in the following part of the text:

   Following this, the mobile node sends the
   binding update message to the home agent. In order to be able to send
   the binding update, the mobile node needs to use the new care-of
   address, which is different from the care-of address used in the
   existing tunnel. This should be done without permanently updating the
   tunnel with the home address to allow the mobile node to receive
   packets on the old care-of address until the binding acknowledgement
   is received. The method used to achieve this effect is implementation
   dependent and is outside the scope of this specification.

Assuming that we agree that there is nothing technically wrong with the
text, do you see the need for adding more detail to this? I want to know
exactly what you're asking so I can update this once and for all.

 > not just emails on the list.

=> Ok, I just want to make sure that we agree that there are no changes to
IPsec implementations or architecture, I thought you were saying that.

 > CoA requires BU messages.

=> I'm not sure I follow, you're talking about the DSMIPv6 module in the HA
right? In the case of NAT, then changing the CoA requires a BU and an IKE
dynamic update for the HA as a whole (DSMIP + IKE)to be informed of the MN's
address . If no NAT, then a BU with the K flag would suffice. Since the
DSMIPv6 module in the HA always knows whether a NAT is present or not, why
is it confused? 

Thanks,
Hesham

---

From: Julien Laganier <[email-masked]>
Date: Thu, 7 Feb 2008 16:23:17 +0100

Hi Hesham,

On Thursday 07 February 2008, Hesham Soliman wrote:
>  > exchanged messages *and* the local state updates in the *order*
>  > they are required to happen. This would not constrain
>  > implementation, as any implementation with the same externally
>  > visible effects would be OK.
>
> => To avoid multiple iterations of the text again, let me reword the
> above to:
> The text needs to discuss the events resulting from the message
> exchanges in the order that they take place. Is this what you want?
> If so, I can re-arrange the text to make it more orderly and I would
> appreciate it if after that you can point out *exactly* the missing
> details.

I fail to see the difference between what you and Pasi are saying and 
thus I am fine with both :)

Could you re-arrange the text as you proposed and send it to the list, 
then Pasi (and others too!) can comment?

>  > > => MIPv6 does similar things architecturally anyway, like
>  > > swapping the home address with the content of the HAO. So, the
>  > > idea of the packet returning to the "calling function" to do
>  > > things to it before sending is not new.
>  >
> => If we talk about forwarding then I don't think there is a change.
> I think what you mean is that some packets will have an IPv4 source
> address that does not match an existing tunnel. Correct me if I
> misunderstood you, but this is addressed in the following part of the
> text:
>
>    binding update message to the home agent. In order to be able to
> send the binding update, the mobile node needs to use the new care-of
> Assuming that we agree that there is nothing technically wrong with
> the text, do you see the need for adding more detail to this? I want
> to know exactly what you're asking so I can update this once and for
> all.

AFAIU, Pasi wants the text to be explicit about the fact that the new 
care-of-address needs to be attached as ancillary data to the BU before 
it is passed to IPsec, and that this information has to survive IPsec 
processing, i.e. it is still present after IPsec processing happened 
and the packet is passed back to DSMIP code, thus DSMIP has access to 
the new care-of address and can fill in the source address of the BU.

This has implication on the use of IPsec since the IPsec architecture 
does not specify how such ancillary data can be passed along with a 
packet through an IPsec stack. Thus this is not implementation 
dependent, since any implementation would need IPsec to handle passing 
such ancillary data.

In other words, I agree with Pasi's request.

Pasi, am I reading you correctly? Feel free to correct me in case I'm 
not.

>  > >  > decrypt the packet (and hand it over to IP forwarding), but
>  > >  > also somehow preserves DSMIPv6-specific information (in
>  > >  > particular, the IP address/port in the outermost IPv4 header)
>  > >  > across the IPsec processing and eventually to the module
>  > >  > processing BUs.
>  > >
>  > > implementation. When I worked on MIPv6 implementations it was
>  > > not difficult to pass additional information around with the
>  > I was not arguing that this is untolerably bad, or that this
>  > cannot be implemented. I was arguing that this is an
>  > architecturally important topic which needs to be discussed in the
>  > document itself, not just emails on the list.
>
> => Ok, I just want to make sure that we agree that there are no
> changes to IPsec implementations or architecture, I thought you were
> saying that.

I think Pasi is actually arguing that this passing of meta-data attached 
to a packet thru an IPsec stack is actually not present in the IPsec 
architecture. As such, it is indeed an extension to the IPsec 
architecture as we know it, and would thus require changes to 
implementations of RFC4301. I think it's pretty clear it's not possible 
to buy an RFC4301 IPsec stack from vendor X and have it work "AS IS" 
together with a DSMIP implementation from vendor Y.

>  > >  > implications, as there are now *two* different ways how
>  >
>  > tunnel mode
>  >
>  > > => What implications do you see? Apart from supporting two
>  >
>  > different
>  >
>  > > methods?
>  >
>  > care-of-address). I find this pretty important thing to mention,
>  > as the reader might otherwise assume that (effectively) changing
>  > the CoA requires BU messages.
>
> => I'm not sure I follow, you're talking about the DSMIPv6 module in
> the HA right? In the case of NAT, then changing the CoA requires a BU
> and an IKE dynamic update for the HA as a whole (DSMIP + IKE)to be
> informed of the MN's address . If no NAT, then a BU with the K flag
> would suffice. Since the DSMIPv6 module in the HA always knows
> whether a NAT is present or not, why is it confused?

Here I'm not sure what the issue is but it seems there's one. Let's try 
to sort that out.

Best,

--julien

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 8 Feb 2008 02:47:21 +1000

> thus I am fine with both :)

=> That's my intention :) I wanted to be absolutely clear that we're on the
same page.
I know this might sound like an overkill but given the history of this work
you can never be too sure and we need to get this out very soon.

 > then Pasi (and others too!) can comment?

=> Yes.

 > the new care-of address and can fill in the source address of the BU.

=> That's not how I read the comment on this part of the text, I think Pasi
made that comment for the receiving end. But my response was that there is
no need to pass ancillary information to IPsec because this information can
be kept by the function that calls IPsec and when the packet returns, the
information can be "appended" for the next function. This makes it
implementation dependent and does not change IPsec interfaces.

 > architecture. 

=> But that's exactly the opposite of what I'm suggesting above . I actually
thought Pasi and I were on the same page on this but now I'm confused, Pasi?

Hesham

    As such, it is indeed an extension to the IPsec

---

From: Julien Laganier <[email-masked]>
Date: Thu, 7 Feb 2008 17:24:07 +0100

On Thursday 07 February 2008, Hesham Soliman wrote:
>  > > => To avoid multiple iterations of the text again, let me
>  > reword the
>  > > above to:
>  > > The text needs to discuss the events resulting from the message
>  > > exchanges in the order that they take place. Is this what you
>  > > want? If so, I can re-arrange the text to make it more orderly
>  > > and I would appreciate it if after that you can point out
>  > > *exactly* the missing details.
>  >
>  > I fail to see the difference between what you and Pasi are
>  > saying and
>  > thus I am fine with both :)
>
> => That's my intention :) I wanted to be absolutely clear that we're
> on the same page.
> I know this might sound like an overkill but given the history of
> this work you can never be too sure and we need to get this out very
> soon.
>
>  > Could you re-arrange the text as you proposed and send it to
>  > the list,
>  > then Pasi (and others too!) can comment?
>
> => Yes.

Great!

>  > > Following this, the mobile node sends the
>  > > binding update message to the home agent. In order to be able
>  > > send the binding update, the mobile node needs to use the new
>  > > care-of address, which is different from the care-of address used
>  > > in the existing tunnel. This should be done without permanently
>  > > updating the
>  > > tunnel with the home address to allow the mobile node to receive
>  > > packets on the old care-of address until the binding
>  > > acknowledgement
>  > > is received. The method used to achieve this effect is
>  > > implementation
>  > > dependent and is outside the scope of this specification.
>  > >
>  > > Assuming that we agree that there is nothing technically wrong
>  > > with the text, do you see the need for adding more detail to
>  > > this? I want to know exactly what you're asking so I can update
>  > > this once and for all.
>  >
>  > AFAIU, Pasi wants the text to be explicit about the fact
>  > that the new
>  > care-of-address needs to be attached as ancillary data to
>  > the BU before
>  > it is passed to IPsec, and that this information has to
>  > survive IPsec
>  > processing, i.e. it is still present after IPsec processing 
>  > happened and the packet is passed back to DSMIP code, thus DSMIP 
>  > has access to the new care-of address and can fill in the source
>  > address of the BU.
>
> => That's not how I read the comment on this part of the text, I
> think Pasi made that comment for the receiving end. But my response
> was that there is no need to pass ancillary information to IPsec
> because this information can be kept by the function that calls IPsec
> and when the packet returns, the information can be "appended" for
> the next function. This makes it implementation dependent and does
> not change IPsec interfaces.

Ok, maybe I got confused between receive and transmit sides. 

But anyway, the point is that you can't assume there's a function call. 
That's most likely true only in the case of a native IPsec 
implementation. But IPsec stacks are implemented in so many different 
ways, what if it's a BITS? 

Thus that is not implementation dependent since in every case, if 
someone want to use a given IPsec stack with DSMIP, that stack needs to 
handle survival of that ancillary data attached to a packet.

It is implementation dependent whether or not IPsec processing occurs as 
part of a function call that return a processed packet. If you're using 
a STREAMS based IPsec stack, the function call you'd call for IPsec 
processing will pass the packet to the IPsec STREAMS module and won't 
return the processed packet. 

Thus I think the requirement placed on the IPsec stack that it is able 
to handle meta-data with BUs is not limited to implementation but is an 
architectural extension. IMHO That should be written down.

--julien

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 8 Feb 2008 10:08:53 +1000

> return the processed packet. 

=> Good points. I think that clarifies what I was missing about the
architectural issue. although any interaction within a node is by definition
an "implementation issue" :) this is a serious point that should be
highlighted given the pseudo standard APIs that exist.

=> Sure. 

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Fri, 08 Feb 2008 10:46:30 +0100

Hi Hesham,

All right, looks good -- we seem to be on the same page now.

I'm looking forward to your updated text and progressing the document 
towards IESG.

Best,

--julien

---

From: <[email-masked]>
Date: Fri, 8 Feb 2008 12:52:34 +0200

Hesham Soliman wrote:

> above to: The text needs to discuss the events resulting from the
> message exchanges in the order that they take place. Is this what
> you want? If so, I can re-arrange the text to make it more orderly
> and I would appreciate it if after that you can point out *exactly*
> the missing details.

I think we're on the same page here, but given the complexity of the
topic, getting it nailed down in one iteration may be difficult.

There are two events particularly worth discussing:

- Movement: here the tricky parts (as we discovered in earlier
email discussions) are the specific order of state changes,
especially IPsec-related state.

- Initial connection in IPv4 (when the MN is powered on and contacts
HA for the first time): here the non-obvious details are related to
transport and tunnel mode SAs working in totally different way with
DSMIPv6, and to different tunneling formats. 

(About the latter point, Section 4.1 has some incorrect text about
there being three possible formats for tunneling packets between MN
and HA -- I'm counting five in the current spec: vanilla IP-in-UDP,
IP-in-TLV-in-UDP, IP-in-IP, IP-in-ESP, and IP-in-ESP-in-UDP. The
latter two require quite different treatment at certain points.)

<snip>
>  > I don't find this similar at all. In MIPv6, packets that have 
>  > been through IPsec processing are forwarded just like other 
>  > packets, based on information in the packet headers.
> 

I guess we disagree about this, then; I think that forwarding packets
based on some information which isn't in the packet header would be a
change compared to plain MIPv6.

(Also, IPsec architecture in RFC4301 is not really described in
terms of functional calls, but rather packets flowing through
different components.)

> misunderstood you, but this is addressed in the following part of
> the text:
> 
>    Following this, the mobile node sends the binding update message
>    to the home agent. In order to be able to send the binding
>    update, the mobile node needs to use the new care-of address,
>    which is different from the care-of address used in the existing
>    tunnel. This should be done without permanently updating the
>    packets on the old care-of address until the binding
>    acknowledgement is received. The method used to achieve this
>    effect is implementation dependent and is outside the scope of
>    this specification.
>

The detail I'm concerned is interaction with the IPsec architecture
as specified in RFC 4301 (in terms of packets flowing through
components, not as function calls). DSMIPv6 requires some additions 
to that which, as far as I know, are not present in *any* other use 
of IPsec.

<snip>
> => Ok, I just want to make sure that we agree that there are 
> no changes to IPsec implementations or architecture, I thought you 
> were saying that.

No, I guess we don't agree on that: I think this is a (small) change
to IPsec architecture, and will require changes in many IPsec
implementations.

(Certainly it can be implemented, and it's not untolerably bad
either.)

<snip>
> the HA right? In the case of NAT, then changing the CoA requires a
> BU and an IKE dynamic update for the HA as a whole (DSMIP + IKE)to
> be informed of the MN's address . If no NAT, then a BU with the K
> flag would suffice.  Since the DSMIPv6 module in the HA always knows

Yes, I'm talking about the DSMIPv6 module in the HA. My point is that
the "HA as a whole" may not have consistent view of the CoA: if IPsec
tunnel mode SAs are updated via the IPsec dynamic updates, then the
"effective CoA" (the address where HA actually sends the packets) can
be different than what the DSMIPv6 module thinks it is.

This is a somewhat unobvious property that normal MIPv6 doesn't have,
and IMHO needs explicit discussion in the document.

Best regards,
Pasi

---

From: <[email-masked]>
Date: Fri, 8 Feb 2008 12:58:11 +0200

Julien Laganier wrote:

> AFAIU, Pasi wants the text to be explicit about the fact that the
> new care-of-address needs to be attached as ancillary data to the BU
> before it is passed to IPsec, and that this information has to
> survive IPsec processing, i.e. it is still present after IPsec
> processing happened and the packet is passed back to DSMIP code,
> thus DSMIP has access to the new care-of address and can fill in the
> source address of the BU.
> 
> This has implication on the use of IPsec since the IPsec
> architecture does not specify how such ancillary data can be passed
> along with a packet through an IPsec stack. Thus this is not
> implementation dependent, since any implementation would need IPsec
> to handle passing such ancillary data.
> 
> Pasi, am I reading you correctly? Feel free to correct me in case
> I'm not.

This is a reasonably accurate summary of my concern here. Note that
such ancillary data may be needed in both directions. On HA, the new
CoA from outermost IP header needs to survive IPsec decryption; on
MN, the information needed to correctly forward the packet needs to
survive IPsec encryption -- and the MN's packet forwarding code 
needs extensions so that it actually looks at this data (i.e.
current code for stuffing packets to IP-in-IP tunnels may not
be able to check that ancilliary data to see that actually
some packets need to be tunneled differently.)

Best regards,
Pasi

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 19 Feb 2008 23:13:55 +1000

Hi all, 

Sorry this took a long time but viruses (human ones) don't consider IETF
deadlines! Here is a new take on section 5.1. There is a couple of Pasi's
comments the I didn't include and have some clarifying questions on them
below. Please keep reading after the text. 

Section 5.1:
=============

After the mobile node detects movement it configures a new care-of address.
If the mobile node is in an IPv4-only  network, it removes binding update
list entries for correspondent nodes since route optimisation cannot be
supported.  This may cause inbound packet losses as remote correspondent
node are unaware of such movement. To avoid confusion in  the correspondent
node, the mobile node SHOULD deregister its binding with each correspondent
node by sending a  deregistration binding update. The deregistration binding
update message is tunnelled to the home agent and onto the  correspondent
node.

Following this, the mobile node sends the binding update message to the home
agent. If the mobile node is in an IPv6- enabled network, the binding update
is sent without IPv4/UDP encapsulation. If the mobile node is in an
IPv4-only  network, it encapsulates the BU in UDP/IPv4 as discussed in
sections 4.2 and 4.4. In order to be able to send the binding update while
in an IPv4-only network, the mobile node needs to use the new IPv4 care-of
address in the outer header,  which is different from the care-of address
used in the existing tunnel. This should be done without permanently
updating the tunnel within the mobile node's implementation in order to
allow the mobile node to receive packets on  the old care-of address until
the binding acknowledgement is received. The method used to achieve this
effect is  implementation dependent and is outside the scope of this
specification. 

Upon receiving the binding update message, the home agent updates its
security association to include the mobile  node's address as the tunnel
header IP source address and the new port number. When the mobile node is
located in a  private IPv4 network (which is detected as described above),
the new address and port number are allocated by the NAT.  Based on the
setting of the K flag in the binding update, the home agent updates its IKE
security association to  include the tunnel header IP address as that
received in the outer header of the binding update message. The home  agent
may also need to change NAT traversal fields in the IKE_SA to enable the
dyanmic update of the IP address and  port number based on the reception of
authenticated IKE messages, or authenticated packets using tunnel mode ESP.
The  dynamic updates are described in section 2.23 of RFC 4306. 

In order to allow the DSMIPv6 implementation in the home agent to detect the
presence of a NAT on the path to the  mobile node, it needs to compare the
outer IPv4 source address with the IPv4 address in the alt-care-of address
option. This implies that the information in the outer header will be
preserved after IPsec processing and made  available to the DSMIPv6
implementation in the home agent. Depending on the home agent's
implementation, meeting this  requirement may require changes to the IPsec
implementation. 

The home agent will also enable or disable UDP encapsulation  for outgoing
ESP packets for the purpose of NAT  traversal. If the mobile node were
located in a private IPv4 network the address and port number are likely to
be  wrong as the NAT would likely allocate a different address and port
number to traffic encapsulated in IPsec tunnels or  to IKE messages. Hence,
the mobile node updates the IKE SA in one of two ways. If the K flag was
set, the mobile node  SHOULD send an empty informational message, which
results in the IKE module in the home agent to dynamically update  the SA
information. The IKE implementation in the home agent is REQUIRED to support
this feature. Alternatively, the  IKE SA should be re-negotiated. Note that
updating the IKE SA MUST take place after the mobile node has sent the
binding update and received the acknowledgement from the home agent. 

It is important to note that if the mobile node is located behind a NAT, its
IPv4 care-of address seen by the DSMIPv6  module in the home agent upon
receiving the binding update will differ from the IPv4 care-of address seen
by the IKE  module and the care-of address used for forwarding IPsec tunnel
mode traffic. This is due to the fact that the NAT  will probably allocate a
different IP address and port number to each traffic stream. Hence, it is
probable that  different modules in the home agent will have a different
care-of address that should be used for encapsulating  traffic to the mobile
node.

After successfully processing the binding update, the home agent sends the
binding acknowledgement to the mobile  node's care-of address as received in
the outer header of the packet containing the binding update. 

Upon receiving the binding acknowledgement the mobile node updates its local
Security Association information to  include the tunnel header IP source
address, which is the the home agent's address. The mobile node may also
need to  enable or disable UDP encapsulation for outgoing ESP packets for
the purpose of NAT traversal.

The mobile node MAY use [MOBIKE] to update its IKE SA with the home agent.
Using MOBIKE requires negotiating this  capability with the home agent when
establishing the SA. In this case, the mobile node and the home agent need
not  update their IPsec SAs locally as this step is performed by MOBIKE.
Furthermore, the use of MOBIKE allows the mobile  node to update the SA
independently of the binding update exchange. Hence, there is no need for
the mobile node to  wait for a binding acknowledgement before performing
MOBIKE. The use of MOBIKE is OPTIONAL in this specification.

 > IPsec keep-alives (for port 4500) depending on whether it's behind

=> I assume point 4) above is somewhat related to what we say about point
3). I read section 3.3 of RFC 4555 but I'm still unsure about what to say
here. Are you recommending that we follow the same route as Mobike and use
port 4500 if the MN and HA support it? In this case, I guess there is
something to say about point 4) because 4500 is used even if there is no
NAT. Otherwise, if we only use 4500 if a NAT is detected then it's obvious
that we have to always send kepp alives on port 4500. Am I missing
something? 
If you have suggested text for point 3) that would be great. 

Thanks,
Hesham

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 Feb 2008 13:45:07 +0100

Hello Pasi,

Thanks again for spending time reviewing and discussing the DSMIPv6 
specification. Hesham has posted updated text trying to address the 
concerns you had. We'd really like to resolve any remaining issues you 
might still have before the cut-off on next Monday. 

Would be great if you had time to review the updated text ASAP and posts 
your impressions on the mailing list so that we can discuss the way 
forward.

Thanks, and best regards,

--julien

On Tuesday 19 February 2008, Hesham Soliman wrote:
> Hi all,
>
> Sorry this took a long time but viruses (human ones) don't consider
> IETF deadlines! Here is a new take on section 5.1. There is a couple
> of Pasi's comments the I didn't include and have some clarifying
> questions on them below. Please keep reading after the text.
>
> Section 5.1:
> =============
>
> After the mobile node detects movement it configures a new care-of
> address. If the mobile node is in an IPv4-only  network, it removes
> binding update list entries for correspondent nodes since route
> optimisation cannot be supported.  This may cause inbound packet
> losses as remote correspondent node are unaware of such movement. To
> avoid confusion in  the correspondent node, the mobile node SHOULD
> deregister its binding with each correspondent node by sending a 
> deregistration binding update. The deregistration binding update
> message is tunnelled to the home agent and onto the  correspondent
> node.
>
> Following this, the mobile node sends the binding update message to
> the home agent. If the mobile node is in an IPv6- enabled network,
> the binding update is sent without IPv4/UDP encapsulation. If the
> mobile node is in an IPv4-only  network, it encapsulates the BU in
> UDP/IPv4 as discussed in sections 4.2 and 4.4. In order to be able to
> send the binding update while in an IPv4-only network, the mobile
> node needs to use the new IPv4 care-of address in the outer header, 
> tunnel. This should be done without permanently updating the tunnel
> within the mobile node's implementation in order to allow the mobile
> node to receive packets on  the old care-of address until the binding
> acknowledgement is received. The method used to achieve this effect
> is  implementation dependent and is outside the scope of this
> specification.
>
>
> security association to include the mobile  node's address as the
> tunnel header IP source address and the new port number. When the
> mobile node is located in a  private IPv4 network (which is detected
> as described above), the new address and port number are allocated by
> the NAT.  Based on the setting of the K flag in the binding update,
> the home agent updates its IKE security association to  include the
> tunnel header IP address as that received in the outer header of the
> binding update message. The home  agent may also need to change NAT
> traversal fields in the IKE_SA to enable the dyanmic update of the IP
> address and  port number based on the reception of authenticated IKE
> messages, or authenticated packets using tunnel mode ESP. The 
> dynamic updates are described in section 2.23 of RFC 4306.
>
> In order to allow the DSMIPv6 implementation in the home agent to
> detect the presence of a NAT on the path to the  mobile node, it
> needs to compare the outer IPv4 source address with the IPv4 address
> in the alt-care-of address option. This implies that the information
> in the outer header will be preserved after IPsec processing and made
>  available to the DSMIPv6 implementation in the home agent. Depending
> on the home agent's implementation, meeting this  requirement may
> require changes to the IPsec implementation.
>
> The home agent will also enable or disable UDP encapsulation  for
> outgoing ESP packets for the purpose of NAT  traversal. If the mobile
> node were located in a private IPv4 network the address and port
> number are likely to be  wrong as the NAT would likely allocate a
> different address and port number to traffic encapsulated in IPsec
> tunnels or  to IKE messages. Hence, the mobile node updates the IKE
> SA in one of two ways. If the K flag was set, the mobile node  SHOULD
> send an empty informational message, which results in the IKE module
> in the home agent to dynamically update  the SA information. The IKE
> implementation in the home agent is REQUIRED to support this feature.
> Alternatively, the  IKE SA should be re-negotiated. Note that
> updating the IKE SA MUST take place after the mobile node has sent
> the binding update and received the acknowledgement from the home
> agent.
>
> It is important to note that if the mobile node is located behind a
> NAT, its IPv4 care-of address seen by the DSMIPv6  module in the home
> agent upon receiving the binding update will differ from the IPv4
> care-of address seen by the IKE  module and the care-of address used
> for forwarding IPsec tunnel mode traffic. This is due to the fact
> that the NAT  will probably allocate a different IP address and port
> number to each traffic stream. Hence, it is probable that  different
> modules in the home agent will have a different care-of address that
> should be used for encapsulating  traffic to the mobile node.
>
> After successfully processing the binding update, the home agent
> sends the binding acknowledgement to the mobile  node's care-of
> address as received in the outer header of the packet containing the
> binding update.
>
> Upon receiving the binding acknowledgement the mobile node updates
> its local Security Association information to  include the tunnel
> header IP source address, which is the the home agent's address. The
> mobile node may also need to  enable or disable UDP encapsulation for
> outgoing ESP packets for the purpose of NAT traversal.
>
> The mobile node MAY use [MOBIKE] to update its IKE SA with the home
> agent. Using MOBIKE requires negotiating this  capability with the
> home agent when establishing the SA. In this case, the mobile node
> and the home agent need not  update their IPsec SAs locally as this
> step is performed by MOBIKE. Furthermore, the use of MOBIKE allows
> the mobile  node to update the SA independently of the binding update
> exchange. Hence, there is no need for the mobile node to  wait for a
> binding acknowledgement before performing MOBIKE. The use of MOBIKE
> is OPTIONAL in this specification.
>
>  > 3) The spec has to say something about using port 500 vs. port
>  > 4500 for IPsec traffic, since the text in RFC 4306 Section 2.23
>  > won't work as is (MOBIKE had to deal with this issue as well, see
>  > RFC 4555 Section 3.3).
>  >
> => I assume point 4) above is somewhat related to what we say about
> point 3). I read section 3.3 of RFC 4555 but I'm still unsure about
> what to say here. Are you recommending that we follow the same route
> as Mobike and use port 4500 if the MN and HA support it? In this
> case, I guess there is something to say about point 4) because 4500
> is used even if there is no NAT. Otherwise, if we only use 4500 if a
> NAT is detected then it's obvious that we have to always send kepp
> alives on port 4500. Am I missing something?

---

From: <[email-masked]>
Date: Wed, 20 Feb 2008 12:36:29 +0100

Just a small comment below. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hesham Soliman
> Sent: 19. februar 2008 14:14
> To: 'Julien Laganier'; [email-masked]; [email-masked]
> Subject: [MEXT] DSMIPv6 Security considerations section 5.1
> 

--> "will be" to be replaced with "will have to be"

> implementation, meeting this  requirement may require changes 

Christian

---

From: <[email-masked]>
Date: Wed, 20 Feb 2008 16:14:22 +0200

Hi Hesham,

Thanks for the updated text; this is getting much better.  I'd also
like to see some clarifications elsewhere in the document about the
five (not three, as some text claimed) different encapsulations that
are possible when in IPv4-only network, and how/when they get
used (in particular, how the encapsulation type negotiation in
BU/BAck interacts, or does not interact, with IPsec SPD).

See comments inline:

> From: ext Hesham Soliman [mailto:[email-masked]] 
> Sent: 19 February, 2008 15:14
> To: 'Julien Laganier'; Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: DSMIPv6 Security considerations section 5.1 
> 
> Hi all, 
> 
> Sorry this took a long time but viruses (human ones) don't
> consider IETF deadlines! Here is a new take on section 5.1. There
> is a couple of Pasi's comments the I didn't include and have some
> clarifying questions on them below. Please keep reading after the
> text.
> 
> Section 5.1:
> =============
> 
> After the mobile node detects movement it configures a new
> care-of address.  If the mobile node is in an IPv4-only network,
> it removes binding update list entries for correspondent nodes
> since route optimisation cannot be supported.  This may cause
> inbound packet losses as remote correspondent node are unaware of
> such movement. To avoid confusion in the correspondent node, the
> mobile node SHOULD deregister its binding with each correspondent
> node by sending a deregistration binding update. The
> deregistration binding update message is tunnelled to the home
> agent and onto the correspondent node.

Starting the next paragraph with "following this" suggests that
deregistrations are done before sending BU. If the old care-of
address (and existing tunnel) are no longer working, this obviously
isn't possible (and deregistrations are sent only after tunnel has
been updated).
 
> to the home agent. If the mobile node is in an IPv6- enabled
> network, the binding update is sent without IPv4/UDP
> encapsulation. If the mobile node is in an IPv4-only network, it
> encapsulates the BU in UDP/IPv4 as discussed in sections 4.2 and
> 4.4. 

Maybe "If the mobile node is an IPv4-only network, after IPsec
processing the BU is encapsulated in UDP/IPv4 as discussed in sections
4.2 and 4.4."?

> In order to be able to send the binding update while in an
> IPv4-only network, the mobile node needs to use the new IPv4
> care-of address in the outer header, which is different from the
> care-of address used in the existing tunnel. This should be done
> without permanently updating the tunnel within the mobile node's
> implementation in order to allow the mobile node to receive

Ok so far, but I'd suggest adding text along these lines:

  "This implies that the IP forwarding function (which selects the
  interface or tunnel through which a packet is sent) is not based
  solely on the destination address: some IPv6 packets destined to
  the home agent are sent via the existing tunnel, while BUs are
  sent using the new care-of address. Since BUs are protected by
  IPsec, the forwarding function cannot necessarily determine the
  correct treatment from the packet headers. Thus, the DSMIPv6
  implementation has to attach additional information to BUs, and
  this information has to be preserved after IPsec processing and
  made available to the forwarding function. Depending on the
  mobile node's implementation, meeting this requirement may
  require changes to the IPsec implementation."

Next, I'd suggest some reordering of the text to improve readability
and correctness (I'm reordering the quoted text here):

  "Upon receiving a BU encapsulated in UDP/IPv4, the home agent
  processes it as follows:"
  
> needs to compare the outer IPv4 source address with the IPv4
> address in the alt-care-of address option. This implies that the
> information in the outer header will be preserved after IPsec
> processing and made available to the DSMIPv6 implementation in
> the home agent. Depending on the home agent's implementation,
> meeting this requirement may require changes to the IPsec
> implementation.

Ok.

> Upon receiving the binding update message, the home agent updates
> its security association to include the mobile node's address as
> the tunnel header IP source address and the new port number.
> When the mobile node is located in a private IPv4 network (which
> is detected as described above), the new address and port number
> are allocated by the NAT.

Several nits: Updating the port number here is not correct (it will
be wrong even when no NAT is present). It's not the "tunnel header
IP *source* address" on the HA. There can be more than one
SA. Also, explicitly saying "tunnel mode" would clarify.

Suggested rephrasing:

  "Upon receiving the binding update message, the home agent
  updates its tunnel mode security association to include the
  mobile node's care-of address as the remote tunnel header address,
  and 4500 as the port number."

> If the mobile node were located in a private IPv4 network the
> address and port number are likely to be wrong as the NAT would
> likely allocate a different address and port number to traffic
> encapsulated in IPsec tunnels or to IKE messages.

add "; the mobile node provides the correct values in a separate
exchange, as descibed below."

> outgoing ESP packets for the purpose of NAT traversal. 

Ok.

> Based on the setting of the K flag in the binding update, the
> home agent updates its IKE security association to include the
> tunnel header IP address as that received in the outer header of
> the binding update message.

Hmm -- I guess this means that DSMIPv6 requires the HA to support
the K flag? (i.e. always set it in BAcks if it was set in BU?)
Is this requirement mentioned somewhere else in the spec?

Also, port number needs to be reset for non-NAT case.

  "If the Key Management Mobility Capability (K) bit was set in the
  binding update, the home agent updates its IKE security
  associations to include the mobile node's care-of address as the
  peer address and 4500 as the port number."

> The home agent may also need to change NAT traversal fields in
> the IKE_SA to enable the dyanmic update of the IP address and
> port number based on the reception of authenticated IKE messages,
> or authenticated packets using tunnel mode ESP.  The dynamic
> updates are described in section 2.23 of RFC 4306.

Ok.

Add:

  "As described above, when the mobile node is located in a private
  IPv4 network, the address and port number used for IPsec and IKE
  traffic is not yet known by the home agent at this point."

> Hence, the
> mobile node updates the IKE SA in one of two ways. If the K flag
> was set, 

"in the BAck"? (or is the HA required to support this?)

> the mobile node SHOULD send an empty informational
> message, which results in the IKE module in the home agent to
> dynamically update the SA information. The IKE implementation in
> the home agent is REQUIRED to support this
> feature. Alternatively, the IKE SA should be re-negotiated. Note
> that updating the IKE SA MUST take place after the mobile node
> has sent the binding update and received the acknowledgement from
> the home agent.

Seems OK.
 
> It is important to note that if the mobile node is located behind
> a NAT, its IPv4 care-of address seen by the DSMIPv6 module in the
> home agent upon receiving the binding update will differ from the
> IPv4 care-of address seen by the IKE module and the care-of
> address used for forwarding IPsec tunnel mode traffic. This is
> due to the fact that the NAT will probably allocate a different
> IP address and port number to each traffic stream.  Hence, it is
> probable that different modules in the home agent will have a
> different care-of address that should be used for encapsulating
> traffic to the mobile node.

Suggest moving some of this text to separate subsection, which
should also discuss the complications caused by dynamic updates.

> address as received in the outer header of the packet containing
> the binding update.

Add 

  "Note that if the BU was rejected, the BAck is sent to the same
  address where the BU was received from. This may require special
  treatment in IP forwarding and/or IPsec processing which resembles
  sending of BUs in the mobile node (described above)."

> Upon receiving the binding acknowledgement the mobile node
> updates its local Security Association information to include the

"local tunnel mode Security Associations"

> tunnel header IP source address, which is the the home agent's
> address. 

It probably needs to update both source and destination.
On MN, source is the care-of address; destination is the HA.

> The mobile node may also need to enable or disable UDP
> encapsulation for outgoing ESP packets for the purpose of NAT
> traversal.

", and sending of keep-alives"

> The mobile node MAY use [MOBIKE] to update its IKE SA with the
> home agent.  Using MOBIKE requires negotiating this capability
> with the home agent when establishing the SA. In this case, the
> mobile node and the home agent need not update their IPsec SAs
> locally as this step is performed by MOBIKE.  Furthermore, the
> use of MOBIKE allows the mobile node to update the SA
> independently of the binding update exchange. Hence, there is no
> need for the mobile node to wait for a binding acknowledgement
> before performing MOBIKE. The use of MOBIKE is OPTIONAL in this
> specification.

Hmm, "need not update" is probably not totally correct; 
should it be "MUST NOT" or something? (I'm not totally sure,
but if it's both, it's probably not totally right)

>  > 4500 for IPsec traffic, since the text in RFC 4306 Section
>  > 2.23 won't work as is (MOBIKE had to deal with this issue as
>  > well, see RFC 4555 Section 3.3).
>  > 
>  > IPsec keep-alives (for port 4500) depending on whether it's
>  > behind a NAT or not.
> 
> => I assume point 4) above is somewhat related to what we say
> about point 3). I read section 3.3 of RFC 4555 but I'm still
> unsure about what to say here. Are you recommending that we
> follow the same route as Mobike and use port 4500 if the MN and
> HA support it? 
>
> In this case, I guess there is something to say about point 4)
> because 4500 is used even if there is no NAT. Otherwise, if we
> only use 4500 if a NAT is detected then it's obvious that we have
> to always send kepp alives on port 4500. Am I missing something?

Using port 4500 always (as MOBIKE does) would IMHO be simpler
than switching back and forth between ports 500 and 4500.

(BTW, if you have a temporary draft-of-draft version available
somewhere, I could take a quick look before the submission.)

Best regards,
Pasi

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 23 Feb 2008 08:01:23 +1000

Hi Pasi, 

Thanks for all the comments. Everything is in the text and I'll send it
separately. A couple of responses below. 

 > Is this requirement mentioned somewhere else in the spec?

=> I don't think we need to require this. We should continue with the 3775
philosophy. If the K flag is not supported then other means should be used
to update the IKE SA, i.e. dynamic updates, or rerunning IKE. In many cases
the updates to the IKE SA will need those messages anyway. Agree?

 > "in the BAck"? (or is the HA required to support this?)

=> In the BA, I've corrected this.

 > than switching back and forth between ports 500 and 4500.

=> Ok, I guess this is implicit in your comments already. 

 > somewhere, I could take a quick look before the submission.)

=> I can't send it tonight but will send it to you offline on the weekend,
feel free to let me know before the deadline if you have any comments. I'll
have intermittend connectivity on Monday. 

Thanks for your help with this complex section!

Hesham

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 23 Feb 2008 08:02:21 +1000

Here is the updated section.

node. This is done after the mobile node updates the home agent with its new
location as discussed  below.

The mobile node sends the binding update message to the home agent. If the
mobile node is in an IPv6-enabled network,  the binding update is sent
without IPv4/UDP encapsulation. If the mobile node is in an IPv4-only
network, then after  IPsec processing of the BU message, it encapsulates the
BU in UDP/IPv4 as discussed in sections 4.2 and 4.4. In order  to be able to
send the binding update while in an IPv4-only network, the mobile node needs
to use the new IPv4 care-of  address in the outer header, which is different
from the care-of address used in the existing tunnel. This should be  done
without permanently updating the tunnel within the mobile node's
implementation in order to allow the mobile node  to receive packets on the
old care-of address until the binding acknowledgement is received. The
method used to  achieve this effect is implementation dependent and is
outside the scope of this specification. This implies that the  IP
forwarding function (which selects the interface or tunnel through which a
packet is sent) is not based
solely on the destination address: some IPv6 packets destined to the home
agent are sent via the existing tunnel,  while BUs are sent using the new
care-of address. Since BUs are protected by IPsec, the forwarding function
cannot  necessarily determine the correct treatment from the packet headers.
Thus, the DSMIPv6 implementation has to attach  additional information to
BUs, and this information has to be preserved after IPsec processing and
made available to  the forwarding function, or additional DSMIP processing
added to the forwarding function. Depending on the mobile  node's
implementation, meeting this requirement may require changes to the IPsec
implementation.

Upon receiving the binding update message encapsulated in UDP/IPv4, the home
agent processes it as follows. In order  to allow the DSMIPv6 implementation
in the home agent to detect the presence of a NAT on the path to the mobile
node,  it needs to compare the outer IPv4 source address with the IPv4
address in the alt-care-of address option. This  implies that the
information in the outer header will be preserved after IPsec processing and
made available to the  DSMIPv6 implementation in the home agent. Depending
on the home agent's implementation, meeting this requirement may  require
changes to the IPsec implementation. 

The home agent updates its tunnel mode security association to include the
mobile node's care-of address as the remote  tunnel header address, and 4500
as the port number. If the mobile node were located in a private IPv4
network the
address and port number are likely to be wrong as the NAT would likely
allocate a different address and port number to  traffic encapsulated in
IPsec tunnels or to IKE messages; the mobile node provides the correct
information in a  separate exchange as described below.When the mobile node
is located in a private IPv4 network (which is detected as  described
above), the new address and port number are allocated by the NAT. If the Key
Management Mobility Capability  (K) bit was set in the binding update, the
home agent updates its IKE security associations to include the mobile
node's care-of address as the peer address and 4500 as the port number. The
home agent may also need to change NAT  traversal fields in the IKE_SA to
enable the dyanmic update of the IP address and port number based on the
reception  of authenticated IKE messages, or authenticated packets using
tunnel mode ESP. The dynamic updates are described in  section 2.23 of RFC
4306. As described above, when the mobile node is located in a private IPv4
network, the address  and port number used for IPsec and IKE traffic is not
yet known by the home agent at this point. 

The home agent will also enable or disable UDP encapsulation  for outgoing
ESP packets for the purpose of NAT  traversal. The mobile node updates the
IKE SA in one of two ways. If the K flag was set in the binding
acknowledgement  message, the mobile node SHOULD send an empty informational
message, which results in the IKE module in the home agent  to dynamically
update the SA information. The IKE implementation in the home agent is
REQUIRED to support this  feature. Alternatively, the IKE SA should be
re-negotiated. Note that updating the IKE SA MUST take place after the
mobile node has sent the binding update and received the acknowledgement
from the home agent. 

After successfully processing the binding update, the home agent sends the
binding acknowledgement to the mobile  node's care-of address as received in
the outer header of the packet containing the binding update. Note that if
the  BU was rejected, the BAck is sent to the same address where the BU was
received from. This may require special  treatment in IP forwarding and/or
IPsec processing which resembles sending of BUs in the mobile node
(described  above).

Upon receiving the binding acknowledgement the mobile node updates its local
tunnel mode Security Association  information to include the tunnel header
IP source address, which is the the home agent's address and the tunnel
header IP destination, which is the mobile node's care-of address. The
mobile node may also need to enable or disable  UDP encapsulation for
outgoing ESP packets for the purpose of NAT traversal and the sending of
keep alives.

The mobile node MAY use [MOBIKE] to update its IKE SA with the home agent.
Using MOBIKE requires negotiating this  capability with the home agent when
establishing the SA. In this case, the mobile node and the home agent MUST
NOT  update their IPsec SAs locally as this step is performed by MOBIKE.
Furthermore, the use of MOBIKE allows the mobile  node to update the SA
independently of the binding update exchange. Hence, there is no need for
the mobile node to  wait for a binding acknowledgement before performing
MOBIKE. The use of MOBIKE is OPTIONAL in this specification.

---

From: <[email-masked]>
Date: Mon, 25 Feb 2008 09:32:06 +0200

Hesham Soliman wrote:

> => I don't think we need to require this. We should continue with
> the 3775 philosophy. If the K flag is not supported then other means
> should be used to update the IKE SA, i.e. dynamic updates, or
> rerunning IKE.  In many cases the updates to the IKE SA will need
> those messages anyway. Agree?

I'm OK with not requiring the K flag, but then the text needs to
describe both cases (in the previous version there was some text that
IMHO seemed to assume that K flag is always supported -- but I haven't
checked the latest text yet).

Best regards,
Pasi