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

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 24 Mar 2006 15:07:53 -0800

Joe Touch wrote:
> Caitlin Bestler wrote:
>> Joe Touch wrote:
> ...
>>> 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.
>> 
>> That assumption should be documented in the draft, along with noting
>> that this implies that TCP-AUTH is NOT applicable for applications
>> other than router-to-router communication.
> 
> Actually, it applies more as a limitation of PEPs in general,
> that they do not work where they would alter protected
> contents, and so MUST NOT modify those sorts of packets.
> 
> The issue is whether *they* are compliant, rather than
> TCP-AUTH (or TCP/MD5), because this limitation (of PEPs)
> applies to any transport or network layer protection mechanism.
> 
> Joe

Of course that restriction is *far* more obvious if the 
protection mechanism is IPSEC.

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

---

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

> protection mechanism is IPSEC.

IP at least supports fragmentation and reassembly. TCP _does NOT_.

Consider existing security protocols at IP and TCP: IP security protects
the IP header AND the payload. TCP/MD5 security protects the TCP header
(which includes, via pseudoheader, the IP header) AND the payload.

Neither protocol protects fields _intended_ to be mutable en-route;
both protocols protect ALL fields _intended_ to be immutable.

It doesn't seem advisable to define a new security extension for a
protocol that violates _that_ protocol's notion of what is mutable and
what is not.

Joe