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

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Sat, 25 Mar 2006 10:26:06 -0800

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Friday, March 24, 2006 10:31 PM
> To: Anantha Ramaiah (ananth)
> Cc: [email-masked]
> Subject: Re: [tcpm] draft-bonica and TCP segmentation
> 
> Anantha,
> 
> Anantha Ramaiah (ananth) wrote:
> ...
> >> 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".
> 
> That's called a TCP endpoint. The rest is a matter of intent.

Hmm.. I don't understand which one you are referring as end-point. My
above statement was referring to the TCP interceptors in the middle :
"which takes care of the TCP 3 way handshake on behalf of the client and
then completes the same with the server and after that each and every
segment for the flow needs to be adjusted for the seq# and ack# by the
interceptor".  The below diagram is what I am talking about

[Client]-------------TCP interceptor box------------------[Server]
(TCP endpoint)          (Middle box)                      (TCP endpoint)

Of course if some segments take a different route then we are hosed, but
this works today in the field :)

In the above scenario MD5/IPsec cannot be used. I am not sure if we both
are saying the same thing.

Question becomes: 

Do you guys want to make sure we add some text in the draft which
explicitly states this assumption?

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

<snip>

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

---

From: Joe Touch <[email-masked]>
Date: Sat, 25 Mar 2006 10:33:53 -0800

Anantha Ramaiah (ananth) wrote:
> Hmm.. I don't understand which one you are referring as end-point.

Endpoint, as far as IP is concerned, is the IP destination address.
Ditto for TCP - in particular, for TCP, it's the end with which state is
shared and synchronized.

> My
> interceptor". 

Anything that terminates the TCP handshake on behalf of another endpoint
IS the endpoint of that TCP connection...

> The below diagram is what I am talking about
> 

If the middlebox terminates the client's TCP connection, then what you
have is a proxy system:

client-------------------middlebox

The rest of the connection is irrelevant to that TCP connection.

TCP provides E2E reliable byte-stream communication only between _its_
endpoints.

> In the above scenario MD5/IPsec cannot be used.

That depends:

- if the middlebox has the right keys, then MD5 or IPsec _can_ be used.
In that case, the middlebox _is_ the endpoint of either layer.

- if the middlebox does not have the right keys, then MD5/IPsec has
_correctly_ prevented a man-in-the-middle _attack_ on TCP/IP (respectively).

...
> explicitly states this assumption?

This isn't needed. The fact is that security designed to prevent
man-in-the-middle attacks prevents them. Whether 'attack' is how the
middlebox behavior is intended isn't relevant; any unauthorized (lacking
delegated keys) modification of these packets between the endpoints of
the intended connection _is_ a de-facto attack.

Joe