Subject: [Mip6] Resolution of IKEv2 and DSMIPv6 issue

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 14 Nov 2007 23:58:34 +1000

Hi all, 

This is the last outstanding issue for DSMIPv6. In addition to this issue I
received comments on the draft, mainly editorial from George and Samita.
I'll respond to Samita's non-editorial questions separately. After analysing
all of the alternatives we clearly have no concensus for either alternative
so I asked the chairs and the security reviewers to make this decision for
us. Pasi did a lot of work to flush out solution 2 (thanks!) and I'm
including his analysis below with minor fixes. The conclusion of the
analysis was that solution 2 is preferred, mainly because it doesn't require
any of the changes to the implementation that solution 1 required. So I
believe we should go with that and resolve this issue. 

Please find the complete steps for solution 2 below, with assumptions:

Solution 2 rephrased
===========================
(Pasi Eronen 2007-11-08)

NOTE 1: In this description, the DSMIPv6 tunnel has an 
"encapsulation" property with three different values:
- "UDP for all traffic" is obvious.
- "UDP for ESP-V6HoA-V6HA only" means that all ESP traffic 
   between V6HoA and V6HA is UDP-encapsulated; all other traffic 
   is straight IPv4/6-in-IPv4 (without UDP).
- "IPv4/6-in-IPv6" obvious.

NOTE 2: This example assumes that MOBIKE is not negotiated.

NOTE 3: RFC4877 allows the MN to use tunnel mode for BUs.
Here, transport mode MUST be used.

NOTE 4: This example assumes that UDP encapsulation (for DSMIPv6
tunnel or ESP) is never used with IPv6 (also "forced UDP
encapsulation" can't be used). I.e. MUST NOT do UDP encapsulation when the
mobile node is 
in an IPv6-enabled network. 

Solution 2, IPv6 network -> IPv4 only network 
=============================================

1. The MN updates its DSMIPv6 tunnel as follows:
   local address = V4CoA:DSMIPv6-port
   remote address = V4HA:DSMIPv6-port
   encapsulation = "UDP for all traffic"

2. The MN updates its local binding/routing/something table to 
   tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel.

3. The MN deletes all route optimization entries from its
   binding cache.

4. The MN updates its IKE_SA with the home agent as follows: 
   local address = V4CoA:4500
   remote address = V4HA:4500
   NAT traversal = yes (pessimistic -- will be changed later)

5. The MN updates its *tunnel* mode IPsec SAD entries with 
   the home agent as follows:
   local tunnel header address = V4CoA
   remote tunnel header address = V4HA
   UDP encapsulation = yes (pessimistic -- will be changed later)

6. 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.)
   
7. The MN sends a Binding Update, which looks like this:

   IPv4 header (src=V4CoA, dst=V4HA)
   UDP header (src=DSMIPv6-PORT, dst=DSMIPv6-PORT)
   IPv6 header (src=V6HoA, dst=V6HA)
   Destination Options header
      Home Address option (V6HoA)
   ESP header (transport mode)
   Mobility header
      Binding Update
         IPv4 Care-of Address option (V4CoA)

8. The HA receives a Binding Update 

   IPv4 header (src=NATTED_V4CoA, dst=V4HA)
   UDP header (src=NATTED_DSMIPv6-PORT, dst=DSMIPv6-PORT)
   IPv6 header (src=V6HoA, dst=V6HA)
   Destination Options header
      Home Address option (V6HoA)
   ESP header (transport mode)
   Mobility header
      Binding Update
         IPv4 Care-of Address option (V4CoA)

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

10. The HA updates its local DSMIPv6 tunnel:
   local address = V4HA:DSMIPv6-PORT
   remote address = NATTED_V4CoA:NATTED-DSMIPv6-PORT
   encapsulation = "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA only"

11. The HA updates its binding cache so that traffic to V6HoA and V4HoA
    is sent over the DSMIPv6 tunnel.

12. If the HA supports "K" flag, it updates its IKE_SA as follows:
   local address = V4HA:4500
   remote address = NATTED_V4CoA:4500 
   NAT traversal = yes/no
   (NOTE: remote port number is wrong if doing NAT-T; this
   will be updated below)

13. The HA updates its *tunnel* mode IPsec SAD entries with MN:
   local tunnel header address = V4HA:4500
   remote tunnel header address = NATTED_V4CoA:4500
   UDP encapsulation = yes/no
   (NOTE: remote port number is wrong if doing NAT-T; this
   will be updated below)

14. The HA may also need to update information in its SPD 
   (similarly as MN in step 6).

15. HA replies with a Binding Acknowledgement.

   IPv4 header (src=V4HA, dst=NATTED_V4CoA)
   UDP header (src=DSMIPv6-PORT, dst=NATTED_DSMIPv6-PORT)
   IPv6 header (src=V6HA, dst=V6HoA)
      Routing header (type 2): V6HoA
   ESP header (transport mode)
   Mobility header
      Binding Acknowledgement
         [NAT detection option]

16. MN updates the DSMIPv6 tunnel depending on the NAT detection option:
   encapsulation = "UDP for all traffic"/"UDP for ESP-V6HoA-V6HA only"

17. The MN updates IKE/IPsec state as follows:

   - "K" flag 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.

   - "K" flag set, no NAT Detection option (and no MOBIKE): 
      - update IKE_SA: NAT traversal = no
      - update tunnel mode IPsec SAs: UDP encapsulation = no
  
   - "K" flag set, NAT Detection option (and no MOBIKE):
      - update IKE_SA: NAT traversal = yes
      - update tunnel mode IPsec SAs: UDP encapsulation = no

18. 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 = V4CoA:NATTED_PORT_4500
 
19. MN sends Binding Updates to delete bindings with all 
   Correspondent Nodes that were using route optimization. 

20. Done

The above steps would basically apply to a move from IPv4 to IPv4 as well.

Solution 2, IPv4 only network -> IPv6 network
=============================================

1. The MN updates its DSMIPv6 tunnel as follows:
   local address = V6CoA
   remote address = V4HA
   encapsulation = "straight IPv4/6-in-IPv6"

2. The MN updates its local binding/routing/something table 
   to tunnel all traffic *from* V6HoA/V4HoA over the DSMIPv6 tunnel
   (note: "from" here means IP header source address, not including
   e.g. Home Address option)

3. The MN updates its IKE_SA with the home agent as follows: 
   local address = V6CoA:4500
   remote address = V6HA:4500
   NAT traversal = no

4. The MN updates its *tunnel* mode IPsec SAD entries with 
   the home agent as follows:
   local tunnel header address = V6CoA
   remote tunnel header address = V6HA
   UDP encapsulation = no

5. 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.)
   
6. The MN sends a Binding Update, which looks like this:

   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)

7. The HA updates its local DSMIPv6 tunnel:
   local address = V6HA
   remote address = V6CoA
   encapsulation = "straight IPv4/6-in-IPv6"

8. The HA updates its binding cache so that traffic to V6HoA 
    and V4HoA is sent over the DSMIPv6 tunnel.

9. If the HA supports "K" flag, it updates its IKE_SA as follows:
   local address = V6HA:4500
   remote address = V6CoA:4500 
   NAT traversal = no

10. The HA updates its *tunnel* mode IPsec SAD entries with MN:
   local tunnel header address = V6HA:4500
   remote tunnel header address = V6CoA:4500
   UDP encapsulation = no

11. The HA may also need to update information in its SPD 
   (similarly as MN in step 6).

12. HA replies with a Binding Acknowledgement.

   IPv6 header (src=V6HA, dst=V6CoA)
      Routing header (type 2): V6HoA
   ESP header (transport mode)
   Mobility header
      Binding Acknowledgement

13. The MN updates IKE/IPsec state as follows:

   - "K" flag 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.

   - "K" flag set:
      - nothing needs to be done

14. MN could send Binding Updates to update bindings with
   Corrrespondent Nodes for route optimization. 

15. Done

Hesham

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: <[email-masked]>
Date: Wed, 14 Nov 2007 15:16:07 +0100

HI,

I think that there might be an un-important mistake here, namely the
BU's are sent with dest option
over the UPD-Ipv4 tunnel, Or ?

Something else: I would have assumed that one could not assume that the
pair
v4CoA:dsmip port and v4CoA:port4500 is mapped to the same natted ip
address (and just different ports).
Doesn't the model need to accommodate that the NAT mapping of the v4CoA
may be different depending on the 
local port, i.e., so that in full generality, we need to operate with a
v4port4500NAT_address and a v4dsmipPortNAT_address, not simply
with one common NATTED_V4CoA - ?

BR, Karen

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Wednesday, November 14, 2007 2:59 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [nemo] Resolution of IKEv2 and DSMIPv6 issue
> 
> Hi all, 
>

---

From: <[email-masked]>
Date: Wed, 14 Nov 2007 15:18:46 +0100

Hi,  

Sorry. I mean to say that RH and dest options are NOT USED over the
UDP-IPv4 dsmip tunnel - right ?

Karen 

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, November 14, 2007 3:16 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [Mip6] RE: [nemo] Resolution of IKEv2 and DSMIPv6 issue
> 
> HI,
>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 14 Nov 2007 23:18:00 -0600

Hesham,

I concur with you that the proposed solution can be accepted as the
resolution to the issue.
Please wait until Friday to see if WG members have any comments or
clarifications needed to the proposal after which time you can include the
text and post the revised I-D prior to the deadline.

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 15 Nov 2007 21:50:18 -0800

All, 
A few notes inline.  

> Sent: Wednesday, November 14, 2007 5:59 AM
> This is the last outstanding issue for DSMIPv6. In addition 
> to this issue I received comments on the draft, mainly 
> editorial from George and Samita.
> I'll respond to Samita's non-editorial questions separately. 
> After analysing all of the alternatives we clearly have no 
> concensus for either alternative so I asked the chairs and 
> the security reviewers to make this decision for us. Pasi did 
> a lot of work to flush out solution 2 (thanks!) and I'm 
> including his analysis below with minor fixes. The conclusion 
> of the analysis was that solution 2 is preferred, mainly 
> because it doesn't require any of the changes to the 
> implementation that solution 1 required. So I believe we 
> should go with that and resolve this issue. 
> 
> NOTE 4: This example assumes that UDP encapsulation (for 
> DSMIPv6 tunnel or ESP) is never used with IPv6 (also "forced 
> UDP encapsulation" can't be used). I.e. MUST NOT do UDP 
> encapsulation when the mobile node is in an IPv6-enabled network. 
> 

I assume steps 4 and 5 above are referring to local changes on the MN
and not messaging between the MN and HA.  It would be good to note that
as such. 

>    (NOTE: remote port number is wrong if doing NAT-T; this

As Karen pointed out, I don't think it can be assumed that the NAT-ed IP
address remains the same and just the port number is going to be
different for IKE usage.  So, I think both need to be updated from the
actual IKE exchange that occurs (more comments on that under step 18
below). 

>    remote_address = V4CoA:NATTED_PORT_4500

IKEv2 allows the change of remote address of the initiator using any IKE
exchange (like the empty informational one mentioned above) only if
NAT-T was detected during the initial IKE exchange (section 2.23 in
RFC4306).  For this, the NAT detection payloads must have been included
in the IKE_SA_INIT message and a mismatch in IP address between that and
the actual IP source/destination address must have been detected.  If
the IKE SA was established when the MN was in a non-NATed v4 or v6
network, then, the MN needs to re-do the full IKE exchange when it moves
to a NAT-ed IPv4 network (I don't believe there is a way around this,
since IKEv2 was written for static nodes).    

I believe the above method uses a shortcut (more hacks to MIP6-IKEv2
interactions, but, who's counting :)) to this and that needs more
clarification in the document.  For instance, in steps 4, 5, 12, and 13,
it appears that the goal is to have the MN and HA locally put the IKE SA
in a state as though it was created in the presence of NATs to begin
with.  In essence, based on detection of NATs by DSMIP6, the IKE SA is
updated as though it got created with NATs.  I have to think about the
implications of this some more; it may be okay to do that.  

However, in the above case, the IKE Informational exchange MUST be
sequentially done, after the BU/BA exchange has occurred.  This is
because the IKE SA state must be updated to indicated NAT-T (based on
the BU/BA) before IP addresses in the SAs can be changed using step 18.
This should be clearly stated as such. 

If the above shortcut is not taken, step 18 will be different for
different cases here: 

A) If the MN is moving from IPv6 or non-NAT-ed IPv4 network into a
NAT-ed IPv4 network, the MN must re-do the IKE exchange to allow NAT
detection 

B) If the MN is moving from a NAT-ed IPv4 network into another NAT-ed
IPv4 network, it can simply use the empty informational exchange
mentioned above. 

So, in conclusion, you either have sequential BU/BA followed by a 1-RT
IKE exchange (any IKE message exchange will work here) or a parallel
BU/BA and 2-RT full IKE exchange to pull this off.   

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 18 Nov 2007 18:01:37 -0800

Hi,

This looks good, So what are we going to add to the draft?
Just mention that transport mode ESP SA MUST be negotiated
for sending a Binding Update? Or are we planning to add all
the details below (that Pasi sent) to the draft? I would
prefer the former.

A couple of minor comments on packet formats below.

>          IPv4 Care-of Address option (V4CoA)

The destination options header would not be present in this BU,
since the home address is already present in the IPv6 header
itself.

>    ESP header (transport mode)

The routing header should not be present in this binding ack,
since the binding ack is already destined to the IPv6 home
address.

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 19 Nov 2007 19:34:49 +1000

I completely agree with Pasi. There is no way we can just say "MUST use
transport mode". We need to clearly explain the process. 

Hesham 

 > From: [email-masked] [mailto:[email-masked]] 
 > Sent: Monday, November 19, 2007 6:04 PM
 > To: [email-masked]; [email-masked]
 > Cc: [email-masked]; [email-masked]
 > Subject: RE: [nemo] Resolution of IKEv2 and DSMIPv6 issue
 > 
 > 
 > I think the discussion so far has shown that "MUST use 
 > transport mode for BU" isn't sufficient -- based on
 > that information only, the reader can't really figure
 > out how this works (or might arrive at quite different
 > solution).
 > 
 > Perhaps not all the details aren't necessary, but
 > as the interaction of local state updates for DSMIPv6,
 > local state updates for IPsec, (DS)MIPv6 messages,
 > and IPsec messages it a bit complex, explaining
 > what happens (and in what order it has to happen)
 > would be IMHO helpful.
 > 
 > Best regards,
 > Pasi 
 > 
 > > From: ext Vijay Devarapalli 
 > [mailto:[email-masked]] 
 > > Sent: 19 November, 2007 04:02
 > > To: Hesham Soliman
 > > Cc: [email-masked]; [email-masked]; Eronen Pasi (Nokia-NRC/Helsinki)
 > > Subject: Re: [nemo] Resolution of IKEv2 and DSMIPv6 issue
 > > 
 > > Hi,
 > >

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 09:38:10 +0100

> the details below (that Pasi sent) to the draft? I would

In my opinion it is important to specify the updating of the IKE_SA, the
IPSEC-SAs,
and potentially the IPSEc SPs that needs to be performed on the basis of
DSMIP signaling at the MN and at the HA respectively.
AS WELL AS how the address and the port information, that is the
(v4port4500NAT_address, NATTED-4500),
is inserted into these by subsequent IKE operation.  

Something else, considering the situation IPv6 network -> IPv4 only
network (but similarly
for the other situations), then I should have thought that step 1 to
step 6 should not be done at the MN
until after it have received the BACK form the HA, that is, not until
after step 15.

Thereby if the BACK is negative, it need not "roll back", assuming that
the old network attachment 
still works. Or is this wrong ?

BR, Karen

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 10:08:24 +0100

> > network (but similarly for the other situations), then I should have
> > thought that step 1 to step 6 should not be done at the MN until
> > after it have received the BACK form the HA, that is, not until
> > after step 15.
> > 
> > Thereby if the BACK is negative, it need not "roll back", assuming
> > that the old network attachment still works. Or is this wrong ?
> 
> Steps 1/2 are required so that the BU actually gets sent
> correctly (without requiring modifications to IPsec).
> 

Ok, I can accept 1/2 before sending BU, at least conceptually.
I think that it is a little implementation dependent, however, whether
the
DSMIP tunnel is set up before or after the receipt of the BACK. I agree,
of course,
that the BU/BACK are sent/received with the tunnel headers, but payload
MUST NOT be
accepted through or from this tunnel before after the receipt of the
BACK (in my opinion).

Where IPSec comes into this, I cannot see. 
I wouldn't expect IPSec to have anything to do with the tunnel headers
headers for the BU/BACK.

Karen

> (If the old network attachment still works, the IPsec stack 
> would see just a packet destined to V6HA, and send it via the 
> old network attachment.)
> 
> Best regards,
> Pasi
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 19 Nov 2007 23:37:20 +1000

Folks, 

This is the current text in the draft. If there are comments we can add them
to the IESG comments, provided there are no major problems here. Thanks for
all the comments. Special thanks to Pasi and Karen for developing the
solution.

Hesham
 
   This specification allows a mobile node to send one binding update
   for its IPv6 and IPv4 home addresses. This is a slight deviation from
   [MIPv6] which requires one binding update per home address. However,
   like [MIPv6], the IPsec security association needed to authenticate
   the binding update is still based on the mobile node's IPv6 home
   address. Therefore, in order to authorize the mobile node's IPv4 home
   address binding, the home agent MUST store the IPv4 address
   corresponding to the IPv6 address that is allocated to a mobile node.
   Therefore, it is sufficient for the home agent to know that the IPsec
   verification for the packet containing the binding update was valid
   provided that it knows which IPv4 home address is associated with
   which IPv6 home address. Hence, the security of the IPv4 home address
   binding is the same as the IPv6 binding.

   In effect, associating the mobile node's IPv4 home address with its
   IPv6 home address moves the authorization of the binding update for
   the IPv4 address to the Mobile IPv6 implementation, which infers it
   from the fact that mobile node has an IPv6 home address and the right
   credentials for sending an authentic binding update for such address.

   In cases where this specification is used for NAT traversal, it is
   important to note that it has the same UNSAF vulnerabilities
   associated with RFC 3519. An attacker is able to hijack the mobile
   node's session with the home agent if it can modify the contents of
   the outer IPv4 header. The contents of the header are not
   authenticated and there is no way for the home agent to verify their
   validity. Hence, a man in the middle attack where a change in the
   contents of the IPv4 header can cause a legitimate mobile node's
   traffic to be diverted to an illegitimate receiver independently of
   the authenticity of the binding update message.

   In this specification the binding update message MUST be protected
   using ESP transport mode. When the mobile node is located in an IPv4-
   only network, the binding update message is encapsulated in UDP as
   described earlier. However, UDP MUST NOT be used to encapsulate the
   binding update message when the mobile node is located in an IPv6-
   enabled network. If protection of payload traffic is needed when the
   mobile node is located in an IPv4-only network, encapsulation is done
   using tunnel mode ESP over port 4500 as described in [TUNSEC].

   Handovers within private IPv4 networks or from IPv6 to IPv4 networks
   will have impacts on the security association between the mobile node
   and the home agent. The following section presents the expected
   behaviour of the mobile node and home agent in those situations.

5.1 Handover interactions for IPsec and IKE

   After the mobile node detects movement it updates its tunnel
   information depending on the network capability. If the new link is
   IPv4-only then the mobile node updates its tunnel to UDP using the
   DSMIPv6 port and the local IPv4 address. Furthermore, the mobile node
   updates its local Security Association information to include its
   local IPv4 address and with the remote address being the home agent's
   IPv4 address. The mobile node also removes binding update list
   entries for correspondent nodes since route optimisation cannot be
   supported while the mobile node is in an IPv4-only network. This may
   cause inbound packet losses as remote correspondent node are unaware
   of such movement. Following this, the mobile node sends the binding
   update message to the home agent.

   Upon receiving the binding update message, the home agent updates it
   security association locally to include the mobile node's remote
   address as the IP address received in the outer header. When the
   mobile node is located in a private IPv4 network (which is detected
   as described above), this address is the public address 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
   remote address as that received in the outer header of the binding
   update message. If the mobile node were located in a private IPv4
   network this address is likely to be wrong as the NAT would likely
   allocate a different address to the IKE messages. Hence, the mobile
   node MUST update the IKE SA in one of two ways as follows. 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. 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.

   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.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 19 Nov 2007 07:50:13 -0800

> what happens (and in what order it has to happen)

The problem is some of the steps are very implementation specific.
I can try to come up with some text, in the next couple of days,
that explains what needs to be done in sufficient detail without
tying down someone to a specific implementation.

Vijay

>> From: ext Vijay Devarapalli [mailto:[email-masked]]

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 19 Nov 2007 14:22:03 -0800

Hi Hesham,

Mostly looks good. A few comments below.

Hesham Soliman wrote:

>    IPv4 address. 

IMO, the mobile node should update the IKEv2 SA after receiving
the binding acknowledgment. Not before. Not clear why it is
required to update the IKEv2 SA before sending the binding update
itself.

> The mobile node also removes binding update list
>    of such movement. 

I think we should require the mobile node to reserve tunnel
binding updates to the CNs with zero lifetime to delete binding
cache entries at the CNs. This should done once the DS-MIPv6
tunnel with the home agent is updated. Otherwise there might be
a lot of packets lost.

>    information. Alternatively, the IKE SA should be re-negotiated. 

When would this alternative be used?

If the 'K' flag is not set, you would need a full IKEv2 exchange.

You would need an empty Informational exchange only when the 'K' flag
is set. This is to figure out the NATTED IP address and port for UDP
port 4500.

> Note

This says the IKE SA is updated after the BU/BAck exchange.

Vijay

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 09:18:50 +0100

Hi,  

A few comments below. 

> Sent: Monday, November 19, 2007 2:37 PM
> To: [email-masked]; [email-masked]
> Cc: Nielsen Karen E; [email-masked]
> Subject: Security considerations text
> 
> 
> Folks, 
> 
>    DSMIPv6 port and the local IPv4 address. 

I am still not sure that the tunnel (the MN=HA tunnel) 
should be updated already before the BU/BACK exchange.
I would much prefer a wording which says something like the following:

   "After the mobile node detects movement it must prepare to send a BU
using the new care-of-address.
    How the binding update is sent depends on the network capability. If
the new link is
    IPv4-only then the mobile node much send the BU in a tunnel to UDP
using the
    DSMIPv6 port and the local care-of-address IPv4 address. This may be
achived by the mobile node updating
    its tunnel to the HA in accordance with the new Ipv4 care-of-address
and the UDP tunnelling or it may be achived
    by other means. Note that if the tunnel in between the mobile node
and the home agent is updated, the mobile node MUST NOT accept
    any traffic om this tunnel, except for the BACK itself, before the
BACK from the Home Agent has been received."

Furthermore, the 
> mobile node

I think this should only be done after the receipt of the BACK from the
Home Agent.
IN FACT this needs to be done after the receipt of the BACK (or be
completed at this time), 
because only then will
the MN know whether there is a NAT or not, so only at this point in time
can it appropriately update
the IPSEc SAs to be RFC 3948 ones (if required).

>    security association 

--> security associations
                        -

locally to include the mobile node's remote
>    allocate a different address to the IKE messages. 

There is no mentioning of the ports here. Shouldn't that also be
mentioned ?
Further shouldn't we also say that the type of the tunnel SAs may need
to changed from 
4301 ones to 3948 ones ( [TUNSEC] ?)

Hence, the mobile
BR, Karen

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 20 Nov 2007 13:25:17 +0000

Hi Hesham,
As both Karen and Vijay already indicated, when MOBIKE is not available, the
SA renegotiation can only start after the MN receives the BACK from the HA.
This is already clear at the end of the text you provided but maybe the
first paragraph causes some confusion and could be clarified...possibly as
follows:
"> 5.1 Handover interactions for IPsec and IKE
>    DSMIPv6 port and the local IPv4 address.
After the mobile node registers its IPv4-CoA to the HA, it also updates its
local Security Association information to include its local IPv4 address,
with the remote address being the home agent's IPv4 address."

Finally, for what is worth, I also agree with Vijay (had the same thought
while reading your text) that when the MN moves to IPv4 network, it should
revtunnel BUs to CNs to delete any RO sessions.

Thanks
George
P.S.: Per Jari's suggestion I am moving this to mext mailing list. Good lack
to the new chairs ;-)

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Wed, 21 Nov 2007 00:42:01 +1000

Thanks George, 
 
I must be missing some emails because I only saw one email from Karen on
this. I'm noting all these comments for the meeting. 
 
Hesham

  _____  

From: George Tsirtsis [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2007 11:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [MEXT] Re: [nemo] RE: Security considerations text

Hi Hesham,

Thanks
George

---

From: <[email-masked]>
Date: Wed, 21 Nov 2007 12:33:03 +0200

Hesham Soliman wrote:

> Folks, 
> 
> This is the current text in the draft. If there are comments we can
> add them to the IESG comments, provided there are no major problems
> here. Thanks for all the comments. Special thanks to Pasi and Karen
> for developing the solution.

Couple of small comments:

>    In cases where this specification is used for NAT traversal, it
>    is important to note that it has the same UNSAF vulnerabilities
>    associated with RFC 3519.

"The same NAT-related security vulnerabilities as RFC 3519" would 
be more accurate, as neither this nor RFC 3519 is actually an 
"Unilateral Self-Address Fixing" (UNSAF) mechanism.

<snip>

>    information depending on the network capability. If the new link
>    is IPv4-only then the mobile node updates its tunnel to UDP using
>    the DSMIPv6 port and the local IPv4 address. Furthermore, the
>    mobile node updates its local Security Association information to
>    include its local IPv4 address and with the remote address being
>    the home agent's IPv4 address.

Tunnel mode SAs have two distinct fields, "local address" and "tunnel
header IP source address" (also "local tunnel header address" would be
IMHO acceptable), and it's the latter we're updating here.  Same bug
occurs also later in the text (and also with "remote address").

<snip>
>    The mobile node also removes binding update list entries for
>    correspondent nodes since route optimisation cannot be supported
>    while the mobile node is in an IPv4-only network.

And also "binding cache" entries.

<snip>
>    If the mobile node were located in a private IPv4
>    network this address is likely to be wrong as the NAT 
>    would likely allocate a different address to the IKE messages. 

Should also mention port number, which is certain to be wrong.

As Karen already pointed out, DSMIPv6 also needs to update
the "NAT traversal" state of the IKE_SA, and "UDP encapsulation"
mode of IPsec SAs.

Best regards,
Pasi