RE: [tcpm] draft-bonica and TCP segmentation
"Anantha Ramaiah \(ananth\)" <ananth@cisco.com> Sat, 25 March 2006 19:45 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNEhW-00071m-KZ; Sat, 25 Mar 2006 14:45:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNEhV-00071h-A9 for tcpm@ietf.org; Sat, 25 Mar 2006 14:45:29 -0500
Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNEhU-0005D4-VR for tcpm@ietf.org; Sat, 25 Mar 2006 14:45:29 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 25 Mar 2006 11:45:28 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2PJjS7T007030; Sat, 25 Mar 2006 11:45:28 -0800 (PST)
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 25 Mar 2006 11:45:28 -0800
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [tcpm] draft-bonica and TCP segmentation
Date: Sat, 25 Mar 2006 11:45:28 -0800
Message-ID: <0C53DCFB700D144284A584F54711EC5801599959@xmb-sjc-21c.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] draft-bonica and TCP segmentation
Thread-Index: AcZQOtU1MTP/pPENTV6VrxBvZ9+i0AABlwFw
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: Joe Touch <touch@ISI.EDU>
X-OriginalArrivalTime: 25 Mar 2006 19:45:28.0161 (UTC) FILETIME=[AAE28D10:01C65044]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f
Cc: tcpm@ietf.org
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org
Comments inline... > -----Original Message----- > From: Joe Touch [mailto:touch@ISI.EDU] > Sent: Saturday, March 25, 2006 10:34 AM > To: Anantha Ramaiah (ananth) > Cc: tcpm@ietf.org > Subject: Re: [tcpm] draft-bonica and TCP segmentation > > > > Anantha Ramaiah (ananth) wrote: > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@ISI.EDU] > >> Sent: Friday, March 24, 2006 10:31 PM > >> To: Anantha Ramaiah (ananth) > >> Cc: tcpm@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@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm
- [tcpm] draft-bonica and TCP segmentation Caitlin Bestler
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch
- Re: [tcpm] draft-bonica and TCP segmentation John Heffner
- RE: [tcpm] draft-bonica and TCP segmentation Caitlin Bestler
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch
- Re: [tcpm] draft-bonica and TCP segmentation David Borman
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch
- RE: [tcpm] draft-bonica and TCP segmentation Caitlin Bestler
- RE: [tcpm] draft-bonica and TCP segmentation Anantha Ramaiah (ananth)
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch
- RE: [tcpm] draft-bonica and TCP segmentation Caitlin Bestler
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch
- RE: [tcpm] draft-bonica and TCP segmentation Caitlin Bestler
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch
- RE: [tcpm] draft-bonica and TCP segmentation Anantha Ramaiah (ananth)
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch
- RE: [tcpm] draft-bonica and TCP segmentation Anantha Ramaiah (ananth)
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch
- RE: [tcpm] draft-bonica and TCP segmentation Anantha Ramaiah (ananth)
- Re: [tcpm] draft-bonica and TCP segmentation Joe Touch