Subject: [mobile-ip] Design team recommendation: New recommendation on piggybacking

From: Jari Arkko <[email-masked]>
Date: Tue, 26 Feb 2002 00:57:12 +0200

1. INTRODUCTION

This is a new piggybacking note from the design team that
takes into account some recent discussion on the mailing
list. In the discussion a proposal has been made that
piggybacking could be used unless IPsec policies demand
processing the Binding Updates and payload packets in a
different way.

This note specifies the design team's motivation and current
position. In order to move forward in an efficient manner it
would be beneficial if responses could make it clear they are
- a clarification (by putting CLARIFICATION: in the Subject
   field)
- an issue with a particular point (by ISSUE:)
- disagreement with the conclusion (by CONCLUSION:)

We would also like folks to state for each of our three
separate recommendations whether they AGREE, CAN TOLERATE, or
DISAGREE with them. In case of DISAGREE, please explain why.

2. DISCUSSION

It is perhaps useful to discuss the MIPv6 signaling as a whole
and see where piggybacking can and cannot be applied. Table 1
shows the Binding Request (BR), all RR messages (1a, 1b, 2a,
2b) and the subsequent Binding Update to the CN (RR/BU and
RR/BA), as well as the BU sent to the HA (HA BU/BA).

Message  Sndr Rcvr ViaHA AddIPscOK RepIPscOK  HAprot  Pig

BR        CN   MN    No    Yes       Yes        No    Yes
RR 1a     MN   CN   Yes    Yes        -         No    Yes*
RR 1b     MN   CN    No    Yes        -         No    Yes*
RR 2a     CN   MN   Yes    Yes        -         Yes    No
RR 2b     CN   MN    No    Yes        -         No     No
RR 3/BU   MN   CN    No    Yes       Yes        No    Yes
RR 4/BA   CN   MN    No    Yes       Yes        No    Yes
HA BU     MN   HA     -     -         -        Yes     No
HA BA     HA   MN     -     -         -        Yes     No

       Table 1: Analysis of MIPv6 control messages

The columns in the table have the following meanings:

- Sndr is the sender of the message.

- Rcvr is the receiver of the message.

- ViaHA is Yes if this particular message is routed through
   the HA. In this case the HA is neither the original sender
   or final receiver of the message.

- AddIpscOk means that additional IPsec on top of the regular
   RR procedures would be useful but not mandatory for this
   message.

- RepIPscOk means that IPsec would be useful as an alternative
   to the RR procedures for this message. (Typically, this
   would mean that some address ownership authorization
   procedures would have to be employed, such as providing the
   IPv6 addresses in SubjAltName of X.509 certificates. It is
   not clear if this can or should be assumed, but the subject
   is not discussed here and for the purposes of this note we
   just assume that it would be possible, and can be assured
   via an API to the MIPv6 stack.)

- HAprot means that the HA should encrypt/decrypt at least
   this message when a message is routed through it, for added
   RR security.

- Pig means that piggybacking is useful and security-wise
   possible.  A '*' after a Yes value indicates that
   piggybacking would be sometimes possible.

   Generally speaking, piggybacking isn't possible in the
   messages with ViaHA=Yes, since the BUs and the payload have
   different source/destination addresses (the HA and the MN
   vs. a CN and the MN). RR messages 1a and 1b can be
   piggybacked only if a BCE entry exists already, if HAO
   reflection needs to be prevented as suggested in
   [2]. Another reason for a conditional use of piggybacking in
   this case is that as we will see later, we do not
   necessarily know during 1a/1b that piggybacking is allowed
   by the receiver. RR message 2a can't be used for
   piggybacking at this stage. Given the ease with which an HA
   could be supplanted by a rogue HA, the MN's HA is still
   unverified and we do not wish to allow attackers to be able
   to steal even a single packet to themselves (in this case a
   rogue HA). RR message 2b can't be used for piggybacking at
   this stage as the CoA is still unverified, and we do not
   wish to allow attackers to be able to steal even a single
   packet to themselves.

Main conclusions from this table are the following:

1) In HAprot, the packets are forwarded by the HA into a
    tunnel to the MN and the HA needs to be able to determine
    whether or not to apply IPsec using the IPsec selectors
    [3]. One HAprot=Yes in the upper four messages means that
    we must use for RR something that is a protocol or a port
    number.

2) RepIPsecOK=Yes for all the BU/BA messages means that they
    too should be protocols or ports. This might go away for
    RR/BU and BA if we didn't need the replacement ipsec
    functionality, but not for HA BU/BA.

3) Existence of RepIPsecOk=Yes anywhere means we must know in
    the implementation of MIPv6 what the IPsec policies
    are. This means either extensions to IPsec policy
    mechanisms in typical implementations, or MIPv6 accessing
    them through an API inside the kernel. No such standardized
    API exists today, and not all products have this feature.
    Some do, however.

4) If we want same format for all BUs and BAs to the CNs and
    HAs, Pig=Yes and Pig=No means that the same format must be
    capable of both allowing and not allowing
    piggybacking. This seems to be possible if before
    considering piggybacking, the sender checks that both the
    data and the signaling parts are without IPsec policy
    rules. This check has to be done by the MIPv6 code, as the
    IPsec layers on both ends can't consider a protocol to be
    both final and non-final.

5) There seems to be many special conditions regarding
    piggybacking RR messages. It may make sense to consider
    piggybacking only BU and BA messages (but on the other
    hand this reduces the overall benefits of piggybacking).

In conclusion, a possible approach to implement MIPv6 in
a way that allows both piggybacking and separate packets
is as follows:

- RR messages 1a/2a have a bit to indicate whether or not the
   sender of the packet is willing to accept piggybacking
   BR/BU/BA packets.

- RR and BR/BU/BA is implemented using a separate IP protocol
   type value.

- The BR/BU/BA packets can contain an optional payload when
   the receiver has indicated in 1a/2a that it is willing to
   receive such packets. Piggybacking can only take place after
   the 1a/2a messages have been exchanged (at least once).

- Piggybacking is not allowed when the BR/BU/BA protocol has a
   non-cleartext IPsec policy or when the potential payload to
   piggyback with the signaling has a non-cleartext IPsec
   policy.

- The receiver of a piggybacked packet must verify both the B*
   part and the payload part against the IPsec policy. If
   either one of them should not be allowed in the clear then
   the whole message must be dropped.

This scheme, however, adds some requirements to MIPv6
compliant nodes. In particular, in order for the MIPv6 code to
know whether it can piggyback a BU, it would have to ask the
IPsec code whether there are any rules that would match the BU
or the data packet and give some other value that Pass. This
adds a requirement for a new API within the IP stack and may
not be possible unless the IPsec implementation has this API
or can be changed.

A crucial observation is, however, that the scheme presented
above allows peers to decide whether they want to receive
piggybacked traffic or not and this decision does not consume
any additional message roundtrips. Hence there does not seem
to be any reason to not allow piggybacking for those nodes
that are willing to take on the requirements for it. It seems
unnecessary though to require this from every node.

The ability of the receivers to have a say in whether they
want to have piggybacked signaling also satisfies concerns
raised by Hesham Soliman and others on piggybacking
implications under hard QoS and channel allocations. In
particular, since not all QoS allocation schemes work
end-to-end, a preference expressed by the peer appears to be
the only way to ensure that the QoS requirements from both
peers are taken into account in the piggybacking decision.

3. RECOMMENDATIONS

The design team recommends the following:

R1. A Separate protocol and/or port should be used for the BR
     message, all RR messages, BU message and BA message.  This
     will allow - but not mandate - the use of current IPsec
     selectors in protecting BUs to the CN and HA, and RR
     messages via the HA. The value of next protocol = none
     must be supported by all MIPv6 compliant nodes in these
     messages.

R2. Reserve some space for preference bits in the RR messages
     1a and 1b, to allow the CN and the MN to describe their
     preferences. Only the space is reserved, but no meaning
     is assigned to the bits.

     The potential use of those bits is to allow a CN, for
     instance, tell the MN that it allows the reception of
     piggybacked signaling. However, compliant nodes can leave
     all the bits as zero. This is necessary in order to allow
     implementations that do not have the API between MIPv6 and
     IPsec.

     There is also other potential use of the bits, e.g.
     selecting some variants of stronger BU authorization
     methods, but these are not discussed here.

R3. The above two recommendations should be placed in the
     MIPv6 RFC. This would allow us to quickly proceed to RFC
     status by bypassing controversial content, have as simple
     RFC and implementations as possible, but still allow
     functionality like piggybacking to be specified without
     interoperability concerns, and used by all nodes who
     support it.

R4. Separate RFCs would define the use of these bits. For
     example, their use in piggybacking would need to define
     the following:

       - Allocate a bit in the reserved space in the RR messages
         1a/2a, and describe its semantics.
       - Describe in detail which messages can use piggybacking,
         if it is allowed, and under which conditions.
       - Rules for sending the optional payload along.
       - Rules for receiving the optional payload.
       - Rules on what to check from the IPsec policy
         before deciding to use piggybacking.

     We recommend that such as an RFC for piggybacking be
     produced immediately. This RFC could be progressed
     independently from the main MIPv6 RFC, and the completion
     of the work on the above rules would not be a requirement
     for the main RFC to be published. Given that the
     specification of what the rules are and what to expect
     from the API could take some time if done carefully, this
     seems to imply that this part is best handled in a
     separate RFC.

     (Similarly for other uses of these bits. Any such future
     specifications would need to also consider any potential
     interactions between different uses of these bits. For
     example, conceivably, other faster BU authentication
     schemes may themselves have implications with respect to
     piggybacking.)

R5. At a future time, IF IPsec selectors can be extended in
     some manner, the RFC described under R4 could be updated
     to extend the rules under which piggybacking is possible
     i.e. no IPsec checks would be necessary any more.

4. REFERENCES

[1] http://www.piuha.net/~jarkko/publications/mipv6/Piggybacking.txt
[2] http://www.piuha.net/~jarkko/publications/mipv6/HAO_Reflection.txt
[3] http://www.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt