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

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




El 06/08/2006, a las 18:59, Iljitsch van Beijnum escribió:

[Does anyone know what has happened to the mailinglist? I only got one message after wednesday and I posted three. I mailed Geoff and Kurtis but to no avail.]

On 6-aug-2006, at 9:36, marcelo bagnulo braun wrote:

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 differently

a 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...

Right. I would like to express this as "if a host has BITW IPsec, the host itself MUST NOT perform shim6 processing" so that if the host does shim6, this happens at or after the BITW module.

The second option isn't an option because information in the packet can't be trusted.

why not?

Because I can make a packet that has my return address but has marcelo@it.uc3m.es in the additional ULID field. This means that demultiplexing the packet on this field without additional security checks allows attackers to inject packets. Additional checks means state and if we have state anyway, being able to look up the context ID or other demux info is not a big deal so there is no reason to have a ULID field.


i think i fully agree with this

I mean i don't think that the ULID option is needed in this case
I mean when we say that the BITW device implements the shim, it means it completelly implements the shim, meaning that it has the shim state, the HBA verification, the HBA state and all the whole lot

I mean, fro the protocol perspective nothing changes, only that the implementation is in hardware in the BITW device, rather than in software...

(Yes, this means that MIPv6 got it wrong.)



but now they are proposing to remove the option (for privacy issues)

regards, marcelo