In your previous mail you wrote:
To make the use of IPsec impossible as a limited alternative is more
arguable. To make shim6 and IPsec compatible is a third topics, the
question was opened by Jim and is not yet closed.
i don't see any problems with IPSec and shim compatibility.... do
you
see any issues/troubles there? could you expand on this?
=> you can read the thread initiated by Jim. To summary there is an
issue
about what should be the traffic selectors and how to implement a BITW
(Bump-in-the-Wire, cf. RFC 4301). As it was already discussed in this
list please send questions directly to me (but solution(s) to the list
:-).
-----Original Message-----
From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]
Sent: Wednesday, July 19, 2006 4:32 AM
To: Bound, Jim
Cc: Brian E Carpenter; shim6@psg.com; Joe Abley
Subject: 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