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

Re: visibility of identifier in shim6 payload packet

[resent from last week]

On 1-aug-2006, at 20:40, Henderson, Thomas R wrote:


My understanding of the potential problem is as follows:



- there are multiple ways to implement IPsec:  BITW, BITS, and native



- BITS and BITW operate below the IP layer.  If these types of IPsec
implementations talk to each other, there should be no problem if the
SPD/SAD is defined on the basis of the locators.
Right. When hosts A and B communicate with A1/B1 there will be a security association for that address pair, when they switch to A2/B2 or whatever, a new SA will be negotiated. 


- there is also no problem if two native IPsec implementations talk to
each other using the ULIDs as the IPsec addresses, with both native
IPsec implementations above the shim6 layer
Right, in this case the IPsec header will already be present when the shim sees the packet so all IPsec is done using the initially chosen address pair (the ULIDs) regardless of what locator the packets end up having in the IP header. 


- there is a potential interoperability problem if a native (host)
implementation with SPD/SAD based on ULIDs tries to set up SAs with BITS 
or BITW implementations, which don't have visibility into the ULIDs.
What would happen in this case is that the initial shim negotiation will use A1/B1 and that works for both ends. However, if A is the native IPsec implementation and it detects a reachability problem it will start probing A2/B2 without an IPsec header. B will try to negotiate an SA for this but this will either confuse A or A will accept and there will be a new A2/B2 SA. However, shim packets from A to B won't use this SA, but shim packets from B to A will. Presumably, B will have a policy that rejects the shim packets unless they're protected, but A will not use IPsec towards B so B wont' see A. A will most likely not process IPsec protected shim packets from B because that would be the wrong IPsec/shim ordering, but of course it could.
In any event, the return routability check will fail so the A2/B2 address pair will not be used.
So nothing bad will happen except a slight waste of time and packets. One option to avoid this would be to reverse our original idea about the layering of shim6 and IPsec and layer the shim above IPsec. Another option would be to detect the situation where the layering is different and either don't do the shim or have the native end reverse its layering. We could do this in shim signalling but this requires BIT* implementations to become aware of shim6. IMO, a better solution would be to handle this in IKE. But then, I'm not involved in IPsec so there could be tons of problems that I'm unaware of...