Subject: [mobile-ip] Closing issue 277 (unexpected H bit value in a BU)

From: Jari Arkko <[email-masked]>
Date: Sun, 27 Apr 2003 15:26:02 +0300

I'm trying to close issue #277, which had to do with the
behaviour of correspondent nodes and home agents when the
value of the H bit does not match the expectations of
the receiver.

The current situation in the document is that 'when RR is used' H=1
causes a silent discard. After this check there's a branch based on
the value of the H bit. For H=1, a wrong prefix or non-HA receiver
causes the 131/132 status codes to be sent back. For H=0 there are no
further checks.

There are several potential issues associated with this.

   1) Inconsistency: If the RR MOs are present on a BU sent to a CN,
      IPsec was on, and H=1, Section 9.5.1 says we should silently
      discard the BU while Section 10.3.1 requires us to send back a
      131 status code. (Counter argument: Section 10.3.1 says that
      Section 9.5.1 validation rules should be checked first, so
      the silent discard has precedence.)

   2) Inconsistency: The H=0 check and the branching rules both look at
      the H flag and can be seen as inconsistent. (Counter argument:
      there's text that indicates the H=0 check is done first and the
      rest is done only if all checks succeed.)

   3) Underspecification: 'When RR is used' does not explicitly say
      whether this means that the MOs in question are present, or that
      the receiver expects to act as a CN.

   4) Debugging difficulties: Due to the silent discard, the MN does
      not learn that there is a problem until much later. (Counter
      argument 1: problem in a security MO shouldn't lead to an answer,
      since its likely an attack and not a bug. Counter argument 2:
      IPsec silently discards faulty IPsec packets, so for the home
      registrations we already have a silent discard behaviour on
      this. Still, non-security related problems should be clearly
      indicated back to the sender.)

In IETF-56 we did not go into the details of this issue, but the
proposal of using RR if and only if H=0 seemed acceptable (with silent
discard if this rule is not followed).

My proposal for the text to close this issue is as follows.
In Section 9.5.1 change the current text:

   "When the return routability procedure is used to enable the
    establishment of nonce indices as inputs to the creation of the
    binding key Kbm, the following are also required:

    o  (List of conditions)

    o  The Home Registration (H) bit MUST NOT be set.

    When using Kbm for validating the Binding Update, the following are
    required:

    o  (Another list of conditions)"

to

   "When the Home Registration (H) bit is set, the following are also required:

    o  (List of conditions)

    o  (Another list of conditions)

    If the Home Registration (H) bit is not set, the Nonce Indices
    mobility option MUST NOT be present."

Note that this approach clarifies issue 3 above. It does not solve
issues 1, 2, or 4, but I think we have good couterarguments why
these issues are not actual problems.

--Jari