[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Peeking into TCP header
Getting this news group back on the subject of security!.
At the recent Hot OS conference there were at least two papers
with proposals for supporting mobile computing by peaking into the
transport (TCP) layer header at intermediate hosts to improve
performance. Peeking into the TCP header has a long history but
I had assumed that the addition of flow id to IP v6 would get rid
of the problem. Unfortunately these new proposals look at the TCP
sequence numbers in addition to the ports. Hence the flow IDs in
IP v6 will not help.
Since IPSEC and IP v6 security will be encrypting the TCP header
if any encryption is performed this could be a problem. There
are three possible approaches to this problem:
1. Tough luck. We are going to encrypt the transport headers and
the Internet will have to live with it. This is a strong justification
for coming up with some form of very cheap privacy, authentication, and
key management scheme to use as the IPSEC default. In addition to what
protection such weak security would offer against attackers it would
provide absolute protection against protocol designers violating
layering constraints. The longer we wait to encrypt transport headers
the more difficult it will be to do.
This is the x-kernel solution. If you want to put encryption at
a higher layer... put encryption at a higher layer. You might want
to make sure you definitions of encryption protocols can be inserted
anywhere in the protocol graph (However because TCP does not
preserve packet boundaries it is hard to get the same crypto-protocol
to work both above TCP and below it). We have done this with our
x-kernel security protocol library. Thus the action item here
might be to form some kind of working group to standardize upper
layer crypto. But it is a problem distinct from IPSEC.
2. support non-end-to-end encryption. We will encrypt TCP headers
but some intermediate hosts will have access to the keys in order
to decrypt enough of the packets to make decisions. This sounds
insecure and will complicate key management especially where the
intermediate host changes over time (as it will with mobile computing).
It would also probably slow done packet processing at the intermediate
host enough to make intermediate processing an untenable option.
3. Modify IPSEC to encrypt only part of the outgoing packet. This essentially
allows IPSEC to pretend to be higher in the protocol suit then it actually
is. Thus you could encrypt the data portion of the TCP packet without
encrypting the header. This sounds intensely ugly. Given variable size
headers the offset into the packet where encryption begins would have
to be calculate on a per packet basis. However if the goal of IPSEC is
to provide a single point for doing all network authentication
(which I think some people believe it is) it is necessary. That is if
you don't do this some applications will require encryption modules
to be inserted in the protocol suite in the higher layers. For example
above TCP or above Sun RPC.
Sean O'Malley