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

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


El 02/08/2006, a las 14:03, Francis Dupont escribió:


 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.



   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.
so, let me ask you another question with respect to BITW and MIPv6 RO operation...
suppose you have a node using MIPv6 in RO mode and it is using BITW IPSec and it receives a packet with the HoA dest option
In order to properly perform the IPSec processing, the HoA must be restored to the IPv6 source address field of the IPv6 header. Since the IPSec processing occurs in the BITW mode, this HoA restoration must occurs in a BITW mode also (i.e. by the IPSec hardware or something below IPSec). Having the HoA in the packet, allows for the BITW not to have to interact with upper parts of the stack to learn the associated HoA, but still part of the HoA dst option processing must occurs in a BITW mode, right?
I think that a similar behaviour occurs for outgoing packets carrying the Routing header, since the including the CoA as the destiantion address in the IPv6 header must be performed after the IPSec processing
So, would it be correct to say that in order to support MIP- IPSec BITW compatibility, the BITW implementation must be updated in order to support part of the MIP processing (in particular, HoA dest option processing and routing header insertion/processing?)
Bottom line is that i think that a reasonable apporach would eb to try to follow the same path that MIPv6 folks have done... 








   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.



i think this may be one option for this particular BITW case
i mean, the other option is that the BITW module can access to shim6 state, but from your words above, i conclude that this is not feasible 



   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.
yes this is another possibility indeed and as i understand this is partialy what is done in MIPv6 with respect to HoA and Routing header processing, right?
i mean, as i understand this, part of the shim6 processing will be performed by the BITW device. I guess we have two options so far: 
- or we integrate all the shim6 processing in the BITW device
- or we include the ULID pair option in data packets (when BITW is in use), so that the BITW device can hace access to all the information that is needed and do not need to perform all the shim6 processing itself 

My suggestion would be to:
- adopt the first option now
- make an extension to shim later so that this BITW optimized mode is supported 

makes sense?

regards, marcelo
- (*) 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