Subject: [mobile-ip] Sending BU with H-bit set to CN

From: Joe Lau <[email-masked]>
Date: Sat, 8 Feb 2003 11:26:19 -0800 (PST)

I need to clarify a change between draft-19 and draft-20.

On draft 19,

9.5.1. Receiving Binding Updates

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

	- BAD option MUS be present ...
	- BAD option MUST be last ...
	- The Home Registration (H) bit MUST NOT be set.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

On draft 20, the 3rd requirement is removed.

This implies that when a BU (with H-bit set) that includes a Nonce Indics
option and a BAD option is sent to a CN,  the latter MUST validate the BU 
the Kbm and return an error status of 131 (home registration not supported)  
_and_  includes an BAD option in the BA.

This is the current TAHI draft-19 conformance test expectation (BA with BAD).
Strictly speaking, TAHI is incorrect per draft-19 but is now correct per
draft-20 :-)

Regards,

Joe

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Feb 2003 12:27:33 +0200

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

We removed the third requirement as a part of issue 177. I think
it was Brian who felt that the H bit treatment is already described
better near the end of Section 9.5.1, and that the use of the auth
methods for binding methods is also described elsewhere in the draft.
See for instance Section 5.1 and the second sentence in Section
10.3.1.

> _and_  includes an BAD option in the BA.

Given end of 9.5.1, start of 5.1, and second sentence in 10.3.1, I would
say that the home BU must have been protected by IPsec in the first
place.

Perhaps there's an additional question on what should happen if
the home registration BU *additionally* contained the nonce indices
and BAD options? But still, 10.3.1 says "MUST authenticate the Binding
Update as described in Section 5.1". Does this leave room for
allowing the authentication to be performed using multiple methods?
I think not...

On the other hand, draft 20 does not say what to do in case you
receive such BUs. Draft 19 silently discarded them. Brian, would
you object to putting the 3rd requirement back in the spec?

Jari

---

From: Joe Lau <[email-masked]>
Date: Sun, 9 Feb 2003 12:23:44 -0800 (PST)

> Jari Arrko wrote:

In addition, I guess we need to clarify what should the CN return to the 
MN when the former receives a BU with H-bit set and Nonce Indics and BAD
included.   What Should the CN do?

	- silently drop BU
	- return BA (status = 131) w/o BAD included
	- return BA (status = 131) with BAD included?

Currently, TAHI expects the 3rd behavior.

Joe

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Feb 2003 22:46:50 +0200

> Currently, TAHI expects the 3rd behavior.

Draft 19 behaviour was to drop the BU. If you look further
down in the text, you will see a rule that says if any of
above tests failed for any other reason than <some exceptions>
then the BU should be silently discarded.

Jari

---

From: Joe Lau <[email-masked]>
Date: Sun, 9 Feb 2003 12:56:58 -0800 (PST)

> then the BU should be silently discarded.

If this is the case, puting back the 3rd requirement to 9.5.1 
will make CN behavior very clear to implementors:

          (was on draft-19 but removed on draft-20)

Thanks!

Joe

---

From: Brian Haley <[email-masked]>
Date: Mon, 10 Feb 2003 12:06:40 -0500

> you object to putting the 3rd requirement back in the spec?

Put it back if it makes it clearer.

But if the H-bit is set we should be following Sections 10.3.1/2,
if we follow 9.5.1 we'll silently drop the packet and not send
code 131 or 133.  Sections 9.5.2/3 make this clear in the first
paragraph that those sections are only for non-H-bit bindings.
I think your question above is valid Jari, there is no text to
say what you do if the BU has NI and BAD and H-bit, I would assume
you'd ignore the NI and BAD and process as if you were the HA.

Other thoughts?

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Feb 2003 12:08:29 +0200

> code 131 or 133.  Sections 9.5.2/3 make this clear in the first

Section 10.3.1 says that 9.5.1 should be followed. I think
this makes the situation now clear, if the H-bit rule
is back in 9.5.1.

Jari

---

From: Yukiyo Akisada <[email-masked]>
Date: Wed, 12 Feb 2003 10:23:51 +0900

Hi,

On Sun, 9 Feb 2003 12:56:58 -0800 (PST)

> will make CN behavior very clear to implementors:

And We (TAHI) will follow this behavior.
Thank you for letting us know.

Regards.

----
Yukiyo Akisada <[email-masked]>