Subject: RE: [tcpm] draft-bonica and TCP segmentation

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Thu, 23 Mar 2006 21:31:14 -0800

It is well known that TCP segments containing the TCP MD5 option (as it
is today) will work on a purely end-to-end principle and cannot be
subject to any further segmentation/proxying at the transport layer by
in-between proxies. Simply because the proxies don't have the keys to
regenerate the TCP segments. By proxies what I mean here is the "trusted
middleboxes" OR NAT's which can rewrite the IP headers and not the
"attacker".

But the TCP MD5 option (and the further revisions that are proposed in
draft-bonica and draft-weis) are mainly for the routing applications and
these connections never find themselves behind a  NAT/firewall or a
proxy device which modifies the TCP segment or the psuedo-header used
for the MD5/new auth option in any manner whatsoever.

This is one of the reasons why there is a 'T' bit present in the TCP
header which tells that whether the TCP options have been omitted while
forming the authentication digest or not. Since we felt that there are
some genuine cases wherein the TCP MSS option can be modified
in-between.

-Anantha

> -----Original Message-----
> From: Caitlin Bestler [mailto:[email-masked]] 
> Sent: Thursday, March 23, 2006 11:08 AM
> To: [email-masked]
> Subject: [tcpm] draft-bonica and TCP segmentation
> 
> >   Whenever TCP generates a segment, it searches the key-chain for an
> >   active key.  Section 6 of this document describes TCPs active key
> >   selection criteria.
> 
> Doesn't this imply that *only* the original sender can do TCP 
> segmentation? I believe the precedent recently reaffirmed for 
> MPA (RDDP WG) was that a protocl MUST NOT assume that the 
> sender's segmetnation would be preserved by the network.
> 
> If message boundaries are lost, a valid network occurrence, 
> how could you interpret the content?
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm
> 

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Mar 2006 13:57:46 -0800

> middleboxes" OR NAT's which can rewrite the IP headers and not the

Any modification of an IP packet in flight - excepting fragmentation of
IPv4, or IP forwarding processing - is equivalent to (and should be
treated as) an attack.

> for the MD5/new auth option in any manner whatsoever.

If these 'trusted middleboxes' can be placed anywhere, and if they are
intended to operate transparently to the ends of a connection, then this
assumption is invalid. While it's reasonable to assume that NATs
shouldn't be placed on a routing path, other "performance enhancing
proxies" (PEPs) can be, and they are the worry.

> some genuine cases wherein the TCP MSS option can be modified

TCP options are part of TCP, and protecting TCP means protecting its
options. If you want that sort of data inspected and modified in the
network, it belongs in the IP header, not TCP.

Joe