[MEXT] DSMIPv6 Security considerations section 5.1

["Hesham Soliman" <Hesham at elevatemobile.com>]

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.



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

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



 > 
 > Best regards, 
 > Pasi


_______________________________________________
MEXT mailing list
MEXT at ietf.org
http://www.ietf.org/mailman/listinfo/mext