Re: the small stuff

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 13-okt-2005, at 7:49, Erik Nordmark wrote:

> > Forking

[...]

> > It might be useful to add a shim exchange that can support  
> > selecting  the right ULIDs in this case, though: that would be  
> > fairly light-weight.

> That would be an option.

> My understanding is that the request to be able to do forking  
> (which we've interpreted as different ULP traffic being able to use  
> different locator pairs to get to the same destination host),

My understanding is that it is having different locators for  
different contexts that use the SAME ULIDs...

> was requested by some transport folks.

> I don't know if we have a mechanism to ask them (whoever they were)  
> whether it is acceptable to do this using a ULID selection  
> mechanism, or whether the ULIDs should be the same but the locators  
> different.

It's hard to have a discussion with an unknown discussion partner.

I think we should certainly take their requirement for this  
functionality very serious, but not necessarily forking as the best  
way to achieve it. But it would be interesting to see feedback from  
transportation folk here, because the mess that this will result in  
is mostly in their back yard: they'll have to color different packets  
such that the application ToS requirements are communicated to the shim.

> In either case, the ULP needs to be updated to be capable to make  
> the shim setup forked context, so I assume there is some  
> flexibility on their end.

If we make this a function of the ULID selection then the  
applications can handle it with a new API without any/much  
involvement from the transports.

> > If we only need longer fields for a very small number of  
> > variables,  it's easier to redefine these variables so that they  
> > are broken in  255-byte chunks and put in two or more fields.

> This is an issue for the shim control messages. They need to be  
> able to carry
>  - lists of locators
>  - CGA parameter data structure
>  - CGA public key signature
> and I think we concluded that at least the last one might be larger  
> than 256 bytes. But I don't know how large the PDS might be.

I'm not sure how many locators you want, but those are only 16 bytes  
so you can have 15 in a max-255-byte option. Yes, crypto will be  
longer but if that's the only thing or pretty much the only thing it  
makes more sense to push the problem to the crypto option, like this  
for a 768 byte piece of crypto data:

type=crypto
len=255
seq=0
<data bytes 0 - 251>
type=crypto
len=255
seq=252
<data bytes 252 - 503>
type=crypto
len=255
seq=504
<data bytes 504 - 755>
type=crypto
len=12
seq=756
<data bytes 756 - 768>

But I guess I can live with 16 bit unaligned length fields...

As long as we avoid mixing alignments, i.e. stuff that is variable  
length in bytes and then something that is n-byte aligned: this needs  
variable length padding and becomes very messy.

> I'm not personally concerned with saving a few bytes in a control  
> message that might be a few hundred bytes.

Me neither, control messages are fair game.

> > Checksums
> > We didn't get a chance to discuss the issues surrounding the  
> > upper  layer checksum. As I've said before, I think we're best off  
> > rewriting  the TCP/UDP checksums along with the addresses. If we  
> > don't do this,  transport checksum calculation offloading will be  
> > a big problem in  IPv6. The potential for harmful actions from  
> > firewalls and such that  don't see a valid checksum is also  
> > significant. Howevever, this is  somewhat related to the  
> > suppressing of the shim header issue.

> And as I've said before, I think this is a very bad idea.
> In some cases, such as ESP, the shim might not be able to rewrite  
> the TCP checksum.

Yes, but as long as this situation is apparent at both ends (the fact  
that you can't see it's TCP because the next header field is  
encrypted is a good clue, but the presence of any AH or ESP header  
too, IMO) this shouldn't be problematic.

> So if we were to do this, then we'd end up with the semantics of  
> the checksum field being different depending on what extension  
> headers are in place.

Yes, that's true.

> I don't understand the statement which ends win "big problem in IPv6".
> Are you assuming that a lot of packets will be sent with a locator  
> pair that is different than the ULID pair?

Well, yes, if we define this as 0 < a lot < all. I don't think the  
actual number makes a difference.

> I think failures are and will be infrequent, so the fraction of  
> shim capable traffic which will be sent with a locator pair that is  
> different than the ULID pair will be vanishingly small.

So? If these packets are filtered out because of an apparently  
invalid checksum we don't have multihoming.

> > Demux on source with shim header

[...]

> I think that *if* we want to keep the door open to routers  
> rewriting the source address field, then we should seriously  
> consider 1) expanding the context tag to 47 bits and 2) look at the  
> security impact of not using the source address as part of the  
> lookup of the context on the receiver.

Yes, that makes sense. (Well, 40 - 44 bits would probably be enough  
too and leave a small number of bits for future use.)

> But I don't get the feeling that the WG has come to consensus on  
> whether we want to consider having routers rewriting the source  
> address.

That's probably because we really haven't solved the ingress  
filtering problem...