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

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 23 Mar 2006 12:37:41 -0800

Joe Touch wrote:
> Caitlin Bestler wrote:
>>>   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?
> 
> That's already part of the TCP spec - TCP is defined only
> between the TCP endpoints; there are no provisions for
> in-network resegmentation, which would affect ACK clocking, Nagle,
> etc. 
> 
>> 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.
> 
> Segmentation at the TCP layer must be preserved, or it's not TCP.
> Network layer re-'segmentation' is a network protocol issue,
> e.g., it is supported in IPv4 but not in IPv6.
> 
> Other transport protocols can make other decisions. TCP could
> be proxied
> - i.e., terminated by an intermediate node and resegmented
> there - but a 'transparent' proxy that does so violates TCP.
> 
> Further, we're talking about authenticated segments;
> resegmentation without resigning the message with the
> appropriate key is basically just an attack - one that fails.
> 

Meaning that a intermediate node that termianted and
re-originated the TCP connections for purely network
reasons would be interpreted as an "attacker".

>> If message boundaries are lost, a valid network occurrence, how could
>> you interpret the content?
> 
> Can you clarify what you mean by 'message'? If you're talking
> about a message boundary within TCP, the application must
> place it there. TCP does not preserve application data units.
> 
> Joe

Doesn't the authentication option effectively makes a "message" out
of each tcp segment, thereby requiring the 'message' boundaries
to be preserved?

MPA was specifically designed to avoid that assumption, despite
the fact that assuming preservation of TCP segments on an end
to end basis would have allowed signifigant design simplifications.

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Mar 2006 13:45:01 -0800

> Joe Touch wrote:
...
> reasons would be interpreted as an "attacker".

That's what it _is_. Esp. if signed, there's no other possibility.

> of each tcp segment, thereby requiring the 'message' boundaries

TCP considers each segment to be a message between its endpoints;
resegmenting those messages is a violation of the protocol.
Unfortunately, that's detectable only if they're protected (TCP/MD5, IPsec).

> to end basis would have allowed signifigant design simplifications.

If MPA is used with a different transport protocol, that's fine.

If MPA is used with TCP and it allows resegmentation, all you have is a
protocol that protects the _data_ of TCP without protecting the segments.

Which won't protect TCP segments from attack (RST, SYN, FIN). It would
provide similar protection that SSL provides - perhaps allowing /
encouraging so-called 'transparent proxies'.

So MPA then protects the data in a way that is "TCP-attacker friendly".
That's a silly optimization IMO.

Joe

---

From: David Borman <[email-masked]>
Date: Thu, 23 Mar 2006 16:24:54 -0600

> protocol that protects the _data_ of TCP without protecting the  

MPA doesn't protect anything.  It identifies record boundaries.

> That's a silly optimization IMO.

I believe the RDDP working group was explicitly told that they  
couldn't change TCP, specifically with regards to segmentation.  MPA  
sits between DDP and TCP, and no assumptions could be made about how  
TCP would segment the data.  MPA does not protect the data, it  
provides a framing mechanism to detect record boundaries, even when  
packets arrive out of order and the records begin in the middle of a  
TCP packet.  It was not a "silly optimization".

The TCP Enhanced Authentication Option would be part of TCP, and so  
the rules are different.  You can't compare MPA and the TCP Enhanced  
Authentication Option.

			-David Borman

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Mar 2006 14:26:54 -0800

To be a little more clear:

if you're using MPA from 'end-to-end' and TCP hop by hop, such as would
be the case with a explicit proxy, then:

	- you're protecting data, not TCP segments

	- there's no guarantee that a single MPA message goes in a
	single TCP segment
		if it's not a TCP option, then it's considered
		the 'user' layer to TCP, and there's no assurance
		of boundary preservation of user messages at the
		TCP layer

	- there's no E2E reliability or in-order delivery guaranteed
	i.e., you can't know that the proxy in the middle didn't
	drop or reorder

If that's what you _really_ want, why not just use TCP over TCP?

I.e., TCP-Auth end-to-end and TCP(with or without auth) hop by hop?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Mar 2006 14:29:06 -0800

> MPA doesn't protect anything.  It identifies record boundaries.

Thanks. Others had discussed this as if it did.

> I believe the RDDP working group was explicitly told that they couldn't
> change TCP, specifically with regards to segmentation.  MPA sits between
> DDP and TCP, and no assumptions could be made about how TCP would
> segment the data.  MPA does not protect the data, it provides a framing
> mechanism to detect record boundaries, even when packets arrive out of
> order and the records begin in the middle of a TCP packet.  It was not a
> "silly optimization".

I was referring to 'protecting the data in a way that's TCP-attacker
friendly' being silly. Record boundaries are very useful.

> The TCP Enhanced Authentication Option would be part of TCP, and so the
> rules are different.  You can't compare MPA and the TCP Enhanced
> Authentication Option.

Agreed.

Joe