Subject: [mobile-ip] Text and proposal for piggybacking

From: Charlie Perkins <[email-masked]>
Date: Fri, 08 Mar 2002 00:30:24 -0800

Hello folks,

This text results from collaboration with Francis Dupont and Jari
Malinen,
who did most of the work.  Together, we hope it will represent a
successful
effort to find the serviceable consensus that enables use of IPsec even
with restrictive interpretation about application of IPsec policy to
final
headers only.

Regards,
Charlie P.

=======================================================================

X.Y    Piggybacking with IPsec

   This section describes when it is possible to piggyback mobility 
   options (BU/BACk and RR messages) while using IPsec and what an 
   implementation needs to do in both the sender and the receiver.

   Two new header types are needed: one extension header for
   piggybacking, and one final header type used with IPsec.
   Since the extension header with payload is not to be protected by
IPsec,
   and the final header type is considered as transport, IPsec does not
   have to be changed at all in any node, peer or intermediate.
   Since these two headers are identical except for their type
   number, the effect on mobility implementation is minimal.

   Interoperation in any case is secured by making piggybacking
   a negotiable option. If node (HA, MN, or CN) can send and receive
   piggybacked packets, it SHOULD initiate or respond in piggybacking
   negotiation by setting the piggybacking flag in the mobility
   signaling as enabled. Also, if the peer in the negotiation does
   not enable its flag, or the node does not receive such a message,
   the node MUST NOT piggyback.

   If IPsec is not used, an implementation can have a policy which 
   by default allows piggybacking, by means of static configuration. 
   Then the node can follow this static configuration and it SHOULD
   enable its own piggybacking flag in the case the configuration is
   set. If there is any non-IPsec reason why the node cannot piggyback,
   this policy can be disabled by a management interface to the policy.
 
   In order to piggyback payload and mobility messages when IPsec 
   is in use, we have cases 1-4 in Table 1. Assuming the current 
   IPsec selectors [RFC 2401] and two new extension headers for 
   mobility signals, the node having IPsec policies (resulting in 
   an AH or ESP header) can piggyback in cases 1 and 2, that is,
   when mobility signaling does not have an IPsec policy.

               Table 1. Piggybacking with IPsec

          IPsec policy for    IPsec policy
          Mobility Message    for Payload    Can piggyback
     1.       no                 no              yes 
     2.       no                 yes             yes
     3.       yes                no              no
     4.       yes                yes             no
  
   In order for the mobility signaling to enforce this, the
   mobility implementation of a sender needs to know whether mobility
   signaling has a non-default policy. It can do this by constructing a 
   signaling packet, making the header type final and causing
   a kernel IPsec policy lookup exactly like current kernel
   IPsec does this for any packet. If no policy exists, the
   final header type MAY be changed to the non-final extension,
   indicating that this signal can be piggybacked. If a policy
   was found, the final header type is used.

   A receiver does not need to have any knowledge of mobility
   in its IPsec processing. The header type hard-codes
   whether a policy even can exist, so if the header is final
   and no policy, or a wrong policy exists, the packet will
   be rejected anyway by IPsec. If the header is a non-final
   extension header, the header type hard codes that
   this signal cannot have an IPsec policy.  Whether the
   receiver accepts the extension signal depends on policy of the
   non-IPsec protection. These policies or their interaction
   with IPsec (re: bidding down or bidding aside prevention)
   cannot be enforced by unmodified IPsec mechanisms.  So
   even with the non-final extension, mobility does not have
   to be IPsec aware and vice versa.

   Piggybacking is not possible on case 3, due to processing
   difficulties at both the sender and the receiver. The scan
   for transport protocol field as described in RFC 2401 seems
   to disallow this mode.  For case 4, conflicting IPsec 
   policies would make it impossible to piggyback.

   Putting the above together, the sender MAY piggyback for the
   cases 1 and 2 in Table 1 and MUST NOT piggyback for cases
   3 and 4.   Equivalently, piggybacking is possible if and
   only if there is no IPsec policy for protection of the
   fields of the mobility signaling header.

X.Z Which Mobility Signals to Piggyback

   An implementation sends piggyback when its negotiation
   result with the peer allows and if it makes sense for
   the mobility signal in question.

   Mobility signals include BR/BU/BAck and the RR messages. 
   Piggybacking of BR/BU/BAck messages between the MN and HA is very
   rare. It can be done only when the payload belongs to a session
   between the MN and HA. For piggybacking between MN and CN,
   Table 2 describes when a mobility signal can be piggybacked.

          Table 2: Mobility Signals and Piggybacking (adapted from 
                   Design Team's writeup with small changes)

     Message                     Sndr       Rcvr          Pig

     Binding Request              CN         MN           Yes
     Binding Update               MN         CN           Yes
     Binding Acknowledgment       CN         MN           Yes
     RR 1a                        MN         CN           Yes*
     RR 1b                        MN         CN           Yes*
     RR 2a                        CN         MN           Yes? 
     RR 2b                        CN         MN            No 

     A (*) indicates that piggybacking would be sometimes possible
     (details in the DT writeup).

     A (?) - cant it be piggybacked?? not sure. didnt quite understand
     what the DT was trying to say about a 'rogue HA'.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Fri, 08 Mar 2002 01:16:37 -0800

Hello,

A correction: paragraph 5:
- s/two new extension headers/two new headers/
- disclaimer: this text tries mostly reflect others'
  ideas on a possible simple compromise proposal where
  minimal change is needed (one negotiation signaling bit 
  and one extra header type). Maybe one line of code is
  needed to hard-code the new transport number in the 2401
  transport scan and an extra pointer to a protocol switch
  receiving a second header type to the mobility code of the
  first header type. An implementation not supporting these
  naturally zeroes its negotiation bit disallowing these
  for a complying peer. A non-compliant packet gets rejected
  if IPsec does not recognize the new transport due to finding
  an unknown protocol type not in its transport policies.
- Ext. header placement could be after the destination option,
  final at the end, both immutable, and no more than one of
  them should exist in a packet.

BR,

-Jari

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Mar 2002 07:53:41 +0100 (CET)

>    piggybacking, and one final header type used with IPsec.

I didn't see a clear explanation in the writeup when each of the two
types would be used. Is it for different cases in Table 1?

  Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 13 Mar 2002 17:58:40 -0800

Erik,
> I didn't see a clear explanation in the writeup when each
> of the two types would be used. Is it for different cases
> in Table 1?

In the writeup, mobility signaling for cases 1 and 2
use the extension header, cases 3 and 4 use the
final header.

BR,

-Jari