[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006

Hi Jim,


El 18/07/2006, a las 18:23, Bound, Jim escribió:


Brian and Joe, (thanks).

If ULID is both ID and Locator that is fine.  Here is more on my issue
and sorry for late response traveling and email is a pain.

If when the packet is transmitted and the Locator is not the ULID, AND
the ULID is the SA to decrypt the packet is my concern.

Here is why.
First that means some form of out-of-band signaling was done to identify a Locator to a ULID so the decrypt can even happen. This is out of scope 
for the IPsec architecture we clearly did not support out-of-band
singaling for IPsec all the way back to the 1994 or 1995 Danvers IETF
meeting when we decided to move to IPsec.

Second I am concerned about implementations that now assume per IPsec
that in fact the Locator is the SA in the arriving or sending packet to
another node.

Does that help?
but isn't the case that there are existent protocols that also use an out of band signaling that you mention below the IPSec layer in a similar fashion that the shim6 protocol (and i think there are valid reasons why to do that)
Let's consider that case of Mobile IPv6 and in particular the case of RO mode 

Suppose that we have a node M that is communicating with a node C
Suppose that node M has a stable address IPH and that node C has an address IPC
Suppose that M and C have established and IPSec protected communication using IPH and IPC (hence the IPSec SA contains IPH and IPC)
Suppose now that node M (which is a mobile node running MIPv6) moves and it gets a new address CoA
Suppose that the communication between M and C is in route optimization mode 

Consider the case of packet flowing from M to node C.
In this case, packets flowing from M to the mobile node C will be carrying CoA in the src address field of the IPv6 header and they will carry the HoA dst option containing the IPH address In addition, the packets carry the ESP/AH header. Since the IPSec SA contains IPH (and not CoA) the IPH must be restored by the MIPv6 layer before the processing. 

Actually, RFC3775 states in page 110 that:

      If route optimization is in use, the mobile node inserts a Home
      Address destination option into the packet, replacing the Source
      Address in the packet's IP header with the care-of address used
      with this correspondent node, as described in Section 11.3.1.  The
      Destination Options header in which the Home Address destination
      option is inserted MUST appear in the packet after the routing
      header, if present, and before the IPsec (AH [5] or ESP [6])
      header, so that the Home Address destination option is processed
      by the destination node before the IPsec header is processed.
This basically means, that upon reception, MIPv6 will restore the original IPH address before the IPSec processing, so that the original addresses/identifers can be used to search the IPSec SA.
As far as i can see this is exactly the same behaviour that is being proposed for the shim, or do you see any difference between the case of the shim6 and mipv6? 

Regards, marcelo





Thanks
/jim


-----Original Message-----
From: Brian E Carpenter [mailto:brc@zurich.ibm.com]
Sent: Tuesday, July 18, 2006 11:04 AM
To: Joe Abley
Cc: Bound, Jim; shim6@psg.com
Subject: Re: IPsec Issue Discussed for Shim6 at IETF Meeting
July 10, 2006

Joe Abley wrote:


On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:


Sure, in my shim6 world the ULID is an initially valid locator.
Of course, it may become invalid dynamically during the

course of a

session, but that will not invalidate the SA as far as I can see.



Surely the ULID is static for the lifetime of a session,

regardless

of what happens to the locator set?


Exactly my point; but if the ULID ceases to work as a
locator, it no longer has its initial duality as both an ID
and a locator.
And I want to be sure than Jim doesn't see a problem in that.

     Brian