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

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Fri, 24 Mar 2006 18:17:29 -0800

Joe, 

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Friday, March 24, 2006 1:58 PM
> To: Anantha Ramaiah (ananth)
> Cc: Caitlin Bestler; [email-masked]
> Subject: Re: [tcpm] draft-bonica and TCP segmentation
> 
> 
> 
> Anantha Ramaiah (ananth) wrote:
> > 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".
> 
> 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.

There are middleboxes out there today which intercepts and completes the
3 way HS with the client and then does the same with the server. After
the connection goes to ESTAB state, the seq# and Ack# are adjusted with
the approproiate "delta".

I am not arguing whether this is the right thing to do or not but yes we
have all these PEP's, TCP interceptors prevailing in today's internet.

> 
> > 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.
> 
> 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.

Point taken.

> 
> > 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.
> 
> 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.

Strictly speaking, yes but again there are boxes out there today (very
common) in some environments doing the adjustment of TCP MSS option in
the middle. Theory and practice are 2 different things.

-Anantha
> 
> Joe
> 
> > -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
> 

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Mar 2006 22:31:12 -0800

Anantha,

...
> the approproiate "delta".

That's called a TCP endpoint. The rest is a matter of intent.

TCP/MD5 and IPsec don't work beyond TCP endpoints or IP destinations,
respectively - whether the endpoint that terminates either is
'authorized' to do so or not.

...
> the middle. Theory and practice are 2 different things.

And so are compliance and noncompliance. To protect TCP but not protect
TCP - to support noncompliant transits that silently modify packet
contents - is to not provide security at the TCP layer.

This is the sort of thing TCP needs protection from. TCP options can be
used as attack vectors.

Joe