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

From: <[email-masked]>
Date: Wed, 30 Jan 2008 14:21:21 +0200

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.

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.

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

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.

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.

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

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.

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