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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

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