On 11/14/2014 8:02 PM, Tero Kivinen wrote:
> As we discussed in the meeting, everybody who cares about the
> integrity protection of the services provided by the TCP headers
> should send email to the list and explain why TCP header bit X should
> be integrity protected, and what kind of attacks are possible if we do
> not protect it.
>
> Also explain what the receiving end should do if it detects attack
> against the protected piece (i.e. either real active attacker attack,
> or middlebox messing that thing up).
IMO a TCP-layer solution is needed only if TCP-level protection is
provided. That's why I think a TCP-level solution should provide some
TCP-level protection.
First, I'm assuming we still want to support TCPINC via NAT traversal,
which excludes:
- TCP/IP SYN source IP (IP in that direction)
- TCP/IP SYN source port
All other fields except those that depend on these *can* be protected
(i.e., the only one that can't is the checksum).
IP options MUST NOT be protected (even if they're IPv6 destination
options, they're not part of the TCP connection). Only the IP
pseudoheader should be protected, and only the portion that can't change
via a NAT (given NAT traversal).
So, IMO, the fields we CAN protect are
IP SYN dest IP
TCP dest port
TCP flags and pointers
TCP seq nos
TCP options
Of these, the only values that are related to privacy would be the IP
and port, but we haven't considered making those private (i.e., we're
focused on data privacy, not connection privacy).
There are NO BENEFITS to the privacy of the data stream in protecting
ANY of these; the benefit is to protecting the TCP connection itself
against attack.
As a result, and because this WG is focused on a TCP solution, I'm in
favor of protecting ALL of these. If we try to get into the business of
deciding how to support middleboxes that play with these fields, then
we'll easily end up with TCP-in-TCP, at which point we ought to just use
BTNS IPsec and go home.
NOTE: regarding RSTs, they can and should be treated like any other
segment. TCPINC connections MUST use keepalives, which means that
they'll clean up after themselves if one side dies. There's NO need for
context-free RSTs.
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
