Re: visibility of identifier in shim6 payload packet (was: Re: IPsec !?...)

[Francis Dupont <Francis.Dupont@point6.net>]

 In your previous mail you wrote:

   I assume that you are pointing out the visibility of the identifier
   in the data packet.  In case of SHIM6, if locator switch is performed
   at the SHIM layer, the source and destination address field of the
   IP header contain locators not the identifiers (in some case they
   might be identical, though).  Now, what implications would this have
   for existing IPsec system?  I assume your point is that BITW IPsec
   device will not be able to extract the information from the IP packet
   for protecting the traffic.  More specifically, BITW IPsec stack may
   want to take the traffic selector information from the packet.
   In this respect, there is a difference between MIP6 RO and SHIM6 in
   its relation to the IPsec.  In case of MIP6, the identifier (=home address)
   is contained in the extended field of the IP header (either in RH2
   or DSTOPT).  Not in SHIM6 case.  Is this the problem that you are
   pointing out?
   
=> yes, this is the main issue.

   Now, let me state my view on this.  I think that the current
   architectural model given in the SHIM6 base protocol document is
   fairly reasonable, and I think we should not change it.
   And I think the above issue is not relevant to security mechanism
   of the SHIM6 protocol (that's why i changed the subject).

=> yes, it is the other side of SHIM6/IPsec interactions.

   Moreover, I would see the above case (BITW) rather minor than
   major.  However, I should admit that I am not familiar with the
   real deployment of BITW IPsec and how common it is to extract
   the information from the packet reached to the BITW device.
   Could you provide me some input how common it is in the BITW
   IPsec scenairo to dynamically extract the information from the
   IP header of the packet?

=> it is always the case: as the BITW is at the wire level it has
only access to the bits on the wire.

   We may also think how much does it make much sense to run SHIM6 in
   case where the BITW device is attached to the host.

=> as IPsec and BITW is already part of the IP architecture, SHIM6
has to accomodate with them.

   BTW, according to RFC4301, BITW device itself
   is IP addressable normally.

=> yes, it has to be managed and perhaps to run IKE so it is better
to give it its own address. BUT this doesn't mean it is a router
(a security gateway in IPsec terminology).

   If this is the case, I tend to think
   that support by SHIM6 does not make much sense in those scenario,
   meaning that the concern is not serious.

=> I strongly disagree: there is no requirement to make IPsec BITWs easy
but there is a clear requirement to be compatible (i.e., not to make
them impossible).

   Anyway, if the concern is really serious,

=> it is, I expect you don't want a last call objection from the military
community and its vendors against the protocol document?

   then we may consider minor modification to
   the SHIM6 payload extension header so that it can provide
   identifier information for the BITW IPsec.  What do you think?
   
=> one way is to put the ULID in all packets. This solves this problem
and related firewall issues too (*). But it is clearly expensive.

   BTW, in case of MIP6, due to the visibility of the identifier
   information, some people are feeling privacy concern and trying
   to hide them from the packet on the wire (in MOBOPTS IPRG).

=> yes, this is the IPsec VPN tentation but multi-homing is very different
because the standard/initial mode hides nothing...

   So, I am feeling that there is no solution that fulfills everyone's
   requirement.  We should focus on the main target, IMHO.
   
=> the main target is to have a protocol which fits into the current
architecture (note this is not yet the case) and solves the problem
(still need to be proved).

Two other points:
 - one possible solution is to integrated the whole SHIM6 into the BITW
   device (i.e., have an IPsec+SHIM6 BITW). As the issue comes from the
   relative positions of the IPsec and SHIM6 sublayer, this makes sense.
 - (*) in MIPv6 the home address is in all packets and fragments for the
   benefit of firewalls (cf RFC 3775 6.3 page 53). IMHO SHIM6 has the same
   concern so a packet or fragment should be easily attached to a
   communication (here easily means without SHIM6 signaling spoofing,
   state handling, etc, both because it is clearly not so easy and
   because one can't assume an intermediate node can see all packets).

Regards

Francis.Dupont@fdupont.fr