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

Results of the IPSEC document reading party

Theodore Y. Ts'o writes:

> Tunnel mode, issue #1:
> 
> Nowhere in the documents is it mentioned what protocol should be used
> in the next header field for tunnel mode. Traditionally, it has been
> protocol 4 (IP-in-IP), which is not really documented anywhere, but
> simply involves encapsulating an entire IP datagram. We think this
> should be made explicit in the architecture document, probably where
> tunnel mode is discussed in section 5.1.2.1 in the architecture
> document (it is implicitely assumed by a reference to rfc2003).

This is a bad idea, because the tunneling which is proposed in the
architecture document is _not_ IP-in-IP.  Of note, rfc2003 states:

   When subsequent datagrams arrive that would transit the tunnel, the
   encapsulator checks the soft state for the tunnel.  If the datagram
   would violate the state of the tunnel (for example, the TTL of the
   new datagram is less than the tunnel "soft state" TTL) the
   encapsulator sends an ICMP error message back to the sender of the
   original datagram, but also encapsulates the datagram and forwards it
   into the tunnel.

while the architecture document reads:

   o PMTU message with 64 bits of IPsec header -- If the ICMP PMTU
     message contains only 64 bits of the IPsec header (minimum for
     IPv4), then a security gateway MUST support the following options
     on a per SPI/SA basis:

        a. if the originating host can be determined (or the possible
            sources narrowed down to a manageable number), send the PMTU
           information to all the possible originating hosts.
        b. if the originating host cannot be determined, store the PMTU
           with the SA and wait until the next packet(s) arrive from the
           originating host for the relevant security association.  If
           the packet(s) are bigger than the PMTU, drop the packet(s),
           and compose ICMP PMTU message(s) with the new packet(s) and
           the updated PMTU, and send the ICMP message(s) about the
           problem to the originating host. Retain the PMTU information
           for any message that might arrive subsequently (see Section
           6.1.2.4, "PMTU Aging").

It has been my experience that this is not an isolated inconsistency.
If we are planning on using IP-in-IP as the tunnel mechanism for IPsec,
then why not simply refer to that RFC?  If not (as seems to be the case)
we'll need to register a new protocol number for IPsec-tunnel-IPv4.  Of
course, I'd ask why bother duplicating an existing protocol in the first
place...

-isakmp-oakley-05.txt
>   2. 3DES-CBC-MAC is not defined. Issues with it are: 1) what to do if the
>      key is exactly 24 bytes; and, 2) what about padding?  Ben Rogers
>      volunteered to write such a description.

I'm guessing that most people will want to take 24 bytes and set the
parity bits appropriately?  (Instead of taking a 21 byte key and
expanding it.)  If I don't hear otherwise, I'll get that written up.



And also, what happened to the output of the arch-sec/ipsec-doi group?
I seem to remember being a part of a rather important discussion which I
thought was more important than should be addressed by that small group
and I'm curious as to what happened to it.


ben
Follow-Ups: References: