Subject: [Hipsec] BEET fall-back mode problem

From: Jan Mikael Melen <[email-masked]>
Date: Fri, 14 Oct 2005 16:03:48 +0300

Hi,

One problem was discovered while implementing the BEET mode for Linux. The 
problem exists in the fall-back to tunnel mode when v4 options are present in 
the inner header. The current version of the draft says in section 5.5:
   4.  If there are any IPv4 header options in the original packet, it
       is RECOMMENDED that they are discarded.  If the inner header
       contains an option that MUST be transported between the tunnel
       end-points, sender MAY encapsulate the inner header in to the ESP
       packet and set the ESP next header as IPv4 (4).  Thus, sender
       MUST encapsulate the whole IP datagram similarly as in tunnel-
       mode.  The inner header contains the BEET mode inner addresses as
       specified in the SA.

This doesn't actually work because the resulting packet would be 
indistinguishable from a normal IPIP tunnel packet that was encapsulated with 
BEET.

The proposed solution would be that we reserve a pseudo-protocol (94) for the 
BEET fall-back mode so that the NH of the ESP would point to this value when 
the fall-back mode is used. So the packet would look like:

          BEFORE APPLYING ESP
     -------------------------------
     |  inner IP hdr  |     |      |
     | (with options) | TCP | Data |
     -------------------------------

          AFTER APPLYING ESP, OUTER v4 ADDRESSES
     -------------------------------------------------------------------
     | outer IP hdr  |     |    | orig IP |     |      |   ESP   | ESP |
     |               | ESP | PH | options | TCP | Data | Trailer | ICV |
     -------------------------------------------------------------------
                           |<------------ encryption ----------->|
                     |<--------------- integrity --------------->|

Where PH is a 4-byte pseudo-header containing only the original NH (IP proto) 
and the length of the original IP options.

Protocol 94 is defined as a yet another IPIP tunneling protocol which is not 
currently used for anything, just being a source of confusion for newbies :-) 
Pekka has taken an action point to request the protocol number to be assigned 
for BEET.

   Regards,
	Jan

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

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 16 Oct 2005 10:40:40 +0200

Small comments:

I'd prefer the PH to be in the standard IPv6 extension header format,
i.e., 8 bytes.

Alternatively, might it be possible and useful to use GRE [RFC 2784]
instead of defining a new extension?  [I doubt, but just in case.]

--Pekka