[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flow label versus Extension header - protocol itself
Hi Greg,
El 27/04/2005, a las 3:47, Greg Daley escribió:
I guess that there need to be some considerations on where the headers
are (TCP, UDP, DestOpt), and their relative position with regards
to IPSec (notably non-null encryption ESP).
Clearly there should be some security mechanism with which to secure
the mapping.
I am not sure what are considering here...
I mean, SHIM data packets will be different to those of MIPv6, becuase
they will not carry multiple addresses for the DST(or src).
I mean in MIPv6, data packets carry both the HoA and the CoA (i.e. the
ULID and the locator)
In shim, data packet will only carry the locator (which sometimes will
also be the ULID, i.e. when no rehoming has occurred)
So in data packets, there is no need to protect no binding since there
won't be any (contained in the data packets)
OTOH, SHIM signaling packets will carry the alternative locators for
the ULID (those are like BU i guess) Those packets do carry binding
information and need to be protected, but they will be protected
through a special SHIM security mechanisms (whether CGA or HBA). I
guess that both the locator and the security information will be
carried in a new extension header defined for shim imho.
It would be good to have sufficient information to
identify which IPSec SA to use (some are identified by address) - this
is the first Dest Option position from RFC2460, and then also to
protect the binding for the identities and locators (either another
destination option (inside ESP from RFC2460), or a payload).
You mean that SHIM is processed before IPSec, right?
In that case, the ULID is restored before IPSec processing...
I guess this is the goal, so that IPSec SA can survive outages, i.e.
that even if locator changes, packets are presented to IPSec as coming
from the ULID
This issue has been visited a few times in SEND (where IPsec wasn't
used
because of multicast, but included because of CGA discussion) and
Mobile IPv6 (Where IPSec is used, but the external header is
unprotected, and needs additional checks).
Right, imho this is the same for SHIM here, The shim header will not
protected by IPSec, but by a specific SHIM security mechanisms (keep in
mind that data packets do not carry any SHIM binding information as
opoosed to MIP)
Where the outside identifier for the signalling isn't globally unique
(and what is...) there's going to be a difficulty in mapping the
identifier if the new message comes from a location not in the set.
Well, i was thinking about this point, and i guess that the packet that
contains a new locator that is not contained in the locator set known
by the peer will need to also carry the SHIM header contianing the
security information to validate that the new locator is securely
associated to the ULID. In this case, if the SHIM header processing is
done before the packet processing (i don't know if this makes any
sense, though), the the result would be:
- A packet containing an unknown locator as source address and also
contains a SHIM header binding the unknown locator to an ULID for which
a SHIM context exists.
So,
- The SHIM header is processed and the new locator contained in the is
verified and added to the locator set available to the ULID
- Next, the IPv6 header is processed, but now the source locator is
contained in the set, so the packet can be demux properly
- The packet is processed by the SHIM and the ULID is restored.
Personally, I guess that it's OK to have two identifiers, one of which
could inhabit a destination option (if it was considered important).
imho this is not needed
what is needed is a context tag in order to demux packets that contain
a locator that differs from the ULID used for the communication. (note
that when the packet carries the ULIDs, there not even the need for a
context tag, it is just a regular IPV6 packet without extension header)
This context tag can be carried in an extension header or flow label.
Regards, marcelo