Re: [Tsvwg] Re: [tcpm] Revision ofdraft-larsen-tsvwg-port-randomization

[Joe Touch <[e-mail]>]

Anantha Ramaiah (ananth) wrote:
> Lars had sent an email to retain focus on the port randomization and
> hence this is going to my last comment... Pl see inline..
>  
>>
>> Anantha Ramaiah (ananth) wrote:
>>> Murari,
>> ...
>>> - or do it in piecemeal, first buy more TCP option space, 
>> standardize 
>>> any one of the proposals for extending the TCP option 
>> space. Then have 
>>> an extended port option like yu suggest below. Then think 
>> about other 
>>> TCP fields requiring extension.
>> The problem is that buying more option space is equivalent to 
>> requiring a whole new TCP header - it has the same problems 
>> with backward compatibility. Previous attempts explored this 
> 
> New TCP header == "Mountain" , IMO this is equivalent to using SCTP in
> some sense.
> 
> TCP option space == "Molehill" , this is a "minimal" change with "some"
> backward compat issues which can be addressed.

This was tried before and was shown to be a mountain of equivalent size
to a new TCP header. The problem is that the space is needed in the SYN,
and there's no backward-compatible way to change the options in the
first packet sent.

> If I take your above para seriously, then you are in a way implying that
> there is no new TCP options possible :-( or in other words users of TCP
> would be rationed to use only a few options in the initial SYN exchange.

I didn't mean to imply that; I meant to state that explcitly.

Joe

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm