Re: [tcpm] New Version Notification for draft-touch-tcpm-tcp-edo-01.txt

[Joe Touch <[e-mail]>]

On May 31, 2014, at 5:55 AM, Olivier Bonaventure <[e-mail]> wrote:

> Joe,
>> 
>> On 5/30/2014 10:53 AM, Olivier Bonaventure wrote:
>> ...
>>> Let me make two rough proposals that could be worth being explored or at
>>> least documented.
>>> 
>>> 1. The TCP option space is limited, but not the IPv6 destination options
>>> in the IPv6 header.
>> 
>> IP option space would not be protected by TCP-AO, and likely not by
>> whatever the TCPUSEC WG creates (e.g.,my proposal is here:
>> http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-01)
> 
> If the destination option is used to transport TCP options,
> then it would define how AO would need to take into account the TCP option inserted by the sender in the IPv6 option.

TCP doesn't necessarily get the entire IP header. It's not practical to claim that TCP-AO can protect something it might never see - and certainly might not have control over once it's inserted in the IPv6 header.


>> Additionally, DPI, NAT processing, etc. are all impacted by IPv6
>> options, so they're generally discouraged AFAIR.
> 
> 
> IPv6 options are much cleaner than IPv4 options. IPv4 options are discouraged because they impact the forwarding on routers. For IPv6 options, this is easier since the option type indicates that the option should only be processed by the destination. For NATs or DPI, supporting TCP options as an IPv6 destination option or as any other proposal would be the same problem

IPv6 options push the location of TCP port numbers to places that need to be computed, rather than being known in advance - and wired into hardware.

Anything that looks at ports might toss something with *any* IP options - v4 or v6 - to slow-path.

Joe