[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Bruce Schneier on IPsec



Stephen,

>
>1) Compression. Van Jacobson-style compression could be used on TCP/IP (and
>other prots now), and is far more efficient that LZS would be on these
>headers.  Perhaps the IPCOMP header need to allow of a marker to tell the
>receiver that Van-J has been used, and this should be added to the IPCOMP
>negotiation in IKE?

maybe.

>2) Tunnel v Transport.  In the mood of simplification, there may be a
>counter arguement to drop 'tunnel-mode' and keep just transport!  In the
>same way that L2TP tunnel traffic is transport-mode protected,  IPIP tunnel
>traffic can be transport-mode protected. This separates IPSEC from
>'tunneling' altogether - a good idea in my mind, since IPIP tunnels have a
>use in their own right.  I know this presents a different model, but it is
>the one we use for LAN-LAN tunnels (L2TP and IPIP) for simplicity.  It
>allows tunnel details (like the fun with MTU) to be left out of the IPSEC
>specs - apart from mentioning security aspects.  Transport-mode protection
>of IPIP tunnel packets = 'IPSEC Tunnel Mode'.

I don't think this works, for several reasons.  First, a critical 
feature of IPsec is the access control provided by comparing the 
"appropriate" headers of traffic to the SA selectors, not only at the 
sender but at the receiver, after decryption.  This feature is lost 
if one uses transport mode even when tunneling, one of the 
shortcomings of L2TP's use of transport mode.  You can't do as good a 
job of access control outside of IPsec, because by then you have lost 
the header info that tells you on which SA a packet was received.

Also, tunneling imposes problems due to MTU changes, in  any case. 
With IPsec,a returned packet may not have enough header data 
available to make it useful to pass to a completely separate IPIP 
tunneling protocol implementation, but IPsec has access to some of 
its header info, which can help in the process.

So, I think that trying to use transport mode, with IPIP tunneling 
above it, will not be a suitable alternative to tunnel mode.

>3) Using AH makes NAT (and Tos mapping) a little difficult. Perhaps 'RSIP'
>will help here. If not for the NAT issues, I think IPIP tunnel traffic
>should be protected with AH+ESP transport mode. With NAT as a problem, just
>ESP transport mode.

Even ESP transport mode fails with NAT, under the current design 
because the TCP header encompasses the IP pseudo header. I have yet 
to look at RSIP, so it may help solve the problem.

>4) Fragmentation - leave this issue to IPIP tunnel specification.
>IPSEC-overhead calculation and be included the MTU maths via a 'system
>service' call, but not
>needed as part of the IPSEC spec.

See comments above re the problems of divorcing fragmentation and MUT 
issues from IPsec.

Steve



References: