El 03/08/2006, a las 19:18, Iljitsch van Beijnum escribió:
On 2-aug-2006, at 15:41, marcelo bagnulo braun wrote:i am not sure what do you mean at the same time.... these would be different ways to implement BITW compatibility that need to be negotiated in the shim6 protocol (or either the processing is done completelly in the BITW device or the ULID pair option is included in the payload header, so that the BITW device can restore the ULIDs)fwiw i am perfectly ok with doing only the first option...So basically this means that IF a host with bump-in-the-wire IPsec support MUST implement the shim in the BITW module and the host itself MUST NOT do shim6?
well i would rephrase it a bit differentlya host may have different shim6 and IPSec implementations, native and BITW If the host is using BITW IPSEc , then if it wants to implement the shim, it must use the BITW shim implementation... after all, if it is using the BITW IPSec, then the packet is already in the hardware device when it enters the IPSec module, and if we want to do something below IPSec we must do it in the hardware device itself, right?
If the host is using native IPSec, the it can use either BITW shim or native shim, since there is no constraints about the packet already being placed in the hardware device
The second option isn't an option because information in the packet can't be trusted.
why not? I mean, what we are talking here is about implementations, right? the protocol and the security features/mechaisms are exactly the same, independetly of the implementation, right? i mean a BITW shim implementation still uses HBAs and other shim6 security features, only that in this case, the processing is implemented in hardware, right?
Regards, marcelo