-----Original Message-----
From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On
Behalf Of marcelo bagnulo braun
Sent: Wednesday, July 19, 2006 3:14 PM
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
El 19/07/2006, a las 19:59, Bound, Jim escribió:
The shim6 spec does have some words about this, in
particular section
1.6 states:
Layering AH and ESP above the multihoming shim means
that IPsec
can
be made to be unaware of locator changes the same way that
transport
protocols can be unaware. Thus the IPsec security associations
remain stable even though the locators are changing.
This means that
the IP addresses specified in the selectors should be
the ULIDs.
however, it would be possible to add additional detailed
description
about how would IPSec processing look like in a shimmed
environment
(whether in the base spec or in the applicability statement)
The above is really not enough it needs to speak to the
actual IPsec
processing and discuss the out-of-band signaling required.
i am not sure i understand...
a description of the IPSec processing is what i mentioned
above, so i guess we agree here
in addition, you suggest to include the out of band
processing, but if i understand correctly this IS the shim6
protocol, since this is the way the alternative locators and
associated security information is conveyed... we could put
it explicitely...
That would help yes. But, the home agent address is
secured with
the mobile node too by IPsec.
i was not cosnidering the communication with the HA but
directly with the CN using RO mode
Same thing from the HA side as it is proxy to the MN.
No, the HA is not involved in the data path when RO mode is used,
in RO mode the data packet flow directly between the MN and
the CN, so
the two cases RO and BT mode are different. The point is that RO mode
requires similar out of band signaling and result in a IPSEc
processing
equal to the one of the shim6 protocol
Making this word change in the spec and having a
discussion would be
progress for sure, and we can then at least discuss security
ramifications. If you go to my very first mail on this the first
input is that the text discussing this part of shim6 is not clear
fixing that is a priori for sure then we can go to next
steps. But
the MIPv6 case is not out of band signaling per se
because the home
agent address was kept with the node when it roamed and did
not have
to be securely negotiated after going mobile. That is a different
network security scenario and property than CGA in shim6.
indeed the communication between the HA and the mobile node
is a different scenario, but the communication between the MN
and the CN in RO mode is exactly the same scenario than a
shim6 communication AFAICT and it uses the exact same type of
out-band signalling, agree?
It is not exactly the same all cohesive security containment is
rigorous on the MN as it owns its HA address.
the point is how oes it proves to the CN that it owns the
HoA... using
IPSec? no, because, similarly to the shim6 case, in order to
use IPSec
for this you would need global PKI. So alternative methods (the so
called out of band signalling) are needed. The result in
terms of IPSec
processing is the same than in shim. Both MIP and shim lie below the
IPSec layer and the translate the locator of received packet to the
original identifiers/home address, so that the IPSec SA can
be searched
using the identifiers and not the locators used to route the packets.
Much different than what we are saying here. Also the CN
still can
perform IPsec processing at the IP layer without popping up to code
for a shim layer.
I don't see why do you day this... MIP needs to restore the
HoA before
the IPSec processing exactly the same that in the shim case,
where the
shim needs to restore the ulids before IPSec processing. In
both cases
the security of the binding between the identifier and the
locators is
not based in IPSec but is this out of band security.
Regards, marcelo
thanks
/jim
regards, marcelo
/jim
-----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
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