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

Re: IPsec Architecture -- proposed changes

> 
> I like most of the changes, however:
> 
> In message <199710070649.CAA15157@relay.hq.tis.com>, Karen Seo writes:
> > 
> >                      <-------- How Outer Hdr Relates to Inner Hdr --------->
> > IPv4                 Outer Hdr at Encapsulator    Inner Hdr at Decapsulator
> >   Header fields
> >     TTL              copy from inner header (2)   copy from outer hdr (2) &
> >                      decrement before forwarding  decrement before forwarding
> 
> This makes traceroute output look really weird when going through a tunnel.
> The question is, should a tunnel look like a single IP hop or not? I'm of
> the VPN religion, and so I believe that tunnels should look like a direct
> (one hop) link between the two hosts/routers.
> 
> Comments?
> 

The tunnel should have it's own TTL. This is consistent with how
other RFCs on tunnelling specify this. Look at RFCs 2003 and 1853
for examples. 


> 
> > 12. How should we ensure interoperable mapping of key material to keys?
> > 
> >     We propose adding the following text to Section 4.6.2 "Automatic
> >     Techniques -- Key Mgt Protocol Requirements"
> 
> The replacement text doesn't handle the case where *both* the encryption and
> authentication algorithms use variable length keys, e.g. RC5 with
> HMAC-SHA1-96. Currently, none of the auth algorithm documents specify a key
> length; there's a defacto standard to use the hash algorithm's digest size,
> but it's not documented anywhere.  ISAKMP allows you to negotiate the length
> of variable keys for encryption, but not for simultaneous authentication.
> This problem needs to be dealt with *somewhere*; I would put it within the
> ISAKMP series somewhere.
> 

Sorry. The auth draft *does* specify it: look at the first paragraph
of section 3:

3. Keying Material
 
   HMAC-SHA-1-96 is a secret key algorithm. While no fixed key length is
   specified in [RFC-2104], for use with either ESP or AH a fixed key
   length of 160-bits MUST be supported.  A key length of 160-bits was
   chosen based on the recommendations in [RFC-2104] (i.e. key lengths
   less than the authenticator length decrease security strength and
   keys longer than the authenticator length do not significantly
   increase security strength).
 
The same for MD5. These are *not* variable-key-length transforms.
There is nothing that suggests that other key sizes are even a MAY,
apart from the reader recalling the history of the older AH drafts. I 
suppose a wordsmith revision could say "this and only this" or 
something which makes the MUST more of a MUST... ;-). 


- C
Follow-Ups: References: