RE: [tcpm] draft-bonica and TCP segmentation

["Anantha Ramaiah \(ananth\)" <ananth at cisco.com>]

Comments inline...

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU] 
> Sent: Saturday, March 25, 2006 10:34 AM
> To: Anantha Ramaiah (ananth)
> Cc: tcpm at ietf.org
> Subject: Re: [tcpm] draft-bonica and TCP segmentation
> 
> 
> 
> Anantha Ramaiah (ananth) wrote:
> >> -----Original Message-----
> >> From: Joe Touch [mailto:touch at ISI.EDU]
> >> Sent: Friday, March 24, 2006 10:31 PM
> >> To: Anantha Ramaiah (ananth)
> >> Cc: tcpm at ietf.org
> >> 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.
> 
> 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.

Well I have seen and heard several ways of describing the endpoint
clause. If we take layering into consideration, for TCP it is qualified
by the 4 tuple (or a 5 tuple) [src addr and port, dest addr and port +
VRF in some cases] But I don't intend to digress here.

> 
> > 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".
> 
> 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
> > 
> > [Client]-------------TCP interceptor box------------------[Server]
> > (TCP endpoint)          (Middle box)                      
> (TCP endpoint)
> 
> If the middlebox terminates the client's TCP connection, then 
> what you have is a proxy system:

Nope. 

TCP interceptor box in the diagram below doesn't "terminate" the TCP
connection. In other words, the middle box doesn't create 2 TCB's for
that "flow" 
The middle box cleverly adjusts the seq# and ack#'s after the connection
goes to ESTAB.. the state info which is kept here is very minimal... You
may chose to call it as a light weight proxy, but it doesn't really
terminate connections.

> 
> client-------------------middlebox
> 
> The rest of the connection is irrelevant to that TCP connection.
> 
> TCP provides E2E reliable byte-stream communication only 
> between _its_ endpoints.
> 
> > 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.
> 
> 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).

Same thoughts here. When I meant IPsec/MD5 cannot be used, I assumed
that the middle box doesn't possess the necessary keys.

> 
> ...
> > Question becomes: 
> > 
> > Do you guys want to make sure we add some text in the draft which 
> > 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.

Ok. I wasn't sure since it was pointed out in the thread that this needs
to be added somewhere in the draft.

Thanks for the discussion.

-Anantha
> 
> Joe
> 

_______________________________________________
tcpm mailing list
tcpm at ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm