Subject: [mobile-ip] Proposed resolutions for issue #177

From: Charlie Perkins <[email-masked]>
Date: Mon, 02 Dec 2002 16:20:45 -0800

It seems to me that these error conditions were considered to be very
serious problems, and I don't remember any specific discussion about why

or why not any action should be taken to counteract possible problems.
I think that if the correspondent node is mobility aware, it should send
a
Binding Error message of some sort.  If it is NOT mobility aware, then
I believe the correspondent node would send ICMP parameter problem.

In order to take some more definite action than just silently ignoring
packets, then, I would suggest returning a Binding Error message from
the correspondent node to the mobile node with new error codes.

Regards,
Charlie P.

Thomas Narten writes:

>    Any packet carrying a Care-of Test Init message which fails to
>    satisfy all of these tests MUST be silently ignored.

huh? why not an ICMP error of some kind? (Silence will cause the MN to
retransmit with the same message...)

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

        Proposal: Send Binding Error with code ?3? to the care-of
address.
==========================================================================

>    Packets carrying Binding Updates that fail to satisfy all of these
>    tests for any reason other than insufficiency of the Sequence
Number
>    or expired nonce index values MUST be silently discarded.

why? (I'm concerned about systematic errors where the MN continues to
retransmit a bogus message because it gets no response).

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

        Proposal: Send Binding Error with code ?4? to the care-of
address.
==========================================================================

---

From: Brian Haley <[email-masked]>
Date: Tue, 03 Dec 2002 11:48:55 -0500

Hi Charlie,

Charlie Perkins wrote:

> a Binding Error message of some sort.  If it is NOT mobility aware, then

So you don't miss it, both HoTI and CoTI sections have the same text to
ignore the packet.  I guess I could live with the BError, but I think it should
be sent to the source address of the packet, or silently discarded if the
address is not unicast routable (refer to section 9.3.3).

> retransmit a bogus message because it gets no response).

I don't know, a BAck seems like the correct response to a BU.

I am curious how this snuck in that section (9.5.1) though:

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

For which we'll drop the packet, but that contradicts what Section
10.3.1 says:

    -  If the node is not a router that implements home agent
       functionality, then the node MUST reject the Binding Update
       and MUST return a Binding Acknowledgement to the mobile node,
       in which the Status field is set to 131 (home registration not
       supported).

I don't think the H-bit stuff needs to be there at all as a few paragraphs
down in that section (9.5.1) it explains what to do if the H-bit is set
or not set.

-Brian

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Dec 2002 22:49:40 +0200

I've been thinking about this issue for a while. It appears that
we have different types of messages:

- Requests with an expectation of a reply (BRR, HOTI, COTI, BU)
- Responses (HOT, COT, BA, BE)
- Error messages (BE)
- Messages with no tests (BRR), minimal tests (HOTI, COTI), and
   messages with complex tests (BU).

I'd like to propose that we exclude responses for error announcements,
because the sender of the response may not have any state for which
the announcement would make a difference. We also need to exclude
error messages from being announced to be faulty, as this might lead
to loops.

This leaves HOTI, COTI, and BU for consideration. Looking at some
similar protocols (eg MLD) it doesn't appear that there's any treatment
of checksum and length errors on simple messages. Therefore, I'd like
to propose that we do not add anything for HOT and COT. The risk of
misimplementing the HOT/COT format is neglible and the error message
specification and implementation just adds the risk of something else
going wrong. For BUs, however, there are fairly complicated tests.
It would make sense to add a new Status code in the BA for "invalid
inding update" to cover for possible problems. (I agree with Brian that
it should be a BA not a BE in this case.)

So my proposal is the following. Add the following to 6.1.8:

     139 Invalid binding update

In 9.5.1, change satisfy-all-of-these-tests paragraph to:

    Packets carrying Binding Updates that fail to satisfy all of these
    tests for any reason other than insufficiency of the Sequence Number
    or expired nonce index values, then the receiving node MUST send back
    a Binding Acknowledgement with status code 139.

In 9.5.4, delete the paragraph:

     -  If the Binding Update was silently discarded as described in
        Section 9.5.1, a Binding Acknowledgement MUST NOT be sent.

and add 139 to the list of status codes for which BAD is not used.

> down in that section (9.5.1) it explains what to do if the H-bit is set

The H bit rule is within a list that applies only if RR is run. So I
think it is fine as is. Or?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 09 Dec 2002 14:18:50 -0800

>     a Binding Acknowledgement with status code 139.

only if the Ack bit is set, right? 

Vijay

---

From: Brian Haley <[email-masked]>
Date: Mon, 09 Dec 2002 19:07:30 -0500

> think it is fine as is. Or?

Actually, this is under the heading "When using Kbm for validating the
Binding Update, the following are required:", not the RR section.
And I believe Charlie wrote a draft using Authdata to protect home
bindings, right?  So we don't want to allow that (I know this is the
CN section :-).  Anyways, is the point you're trying to make that RR
should not be used to authenticate home bindings?  I think that's pretty
well covered in the draft without this.

I agree with the other changes.

Thanks,

-Brian

---

From: Brian Haley <[email-masked]>
Date: Mon, 09 Dec 2002 19:09:50 -0500

> only if the Ack bit is set, right?

No, I think this would fall under "if you didn't change the binding cache you
should tell the MN".

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 09 Dec 2002 16:33:58 -0800

> No, I think this would fall under "if you didn't change the binding cache you

this is new. earlier it used to be the case that HA always sends a 
binding ack if the BU fails, even though the ack bit was not.

but now, the CN is also required to do that???

lets go through section 9.5.1 and see which error code is appropriate. 
it describes the CN processing a binding update.

> 9.5.1. Receiving Binding Updates
> 
>    Before accepting a Binding Update, the receiving node MUST validate
>    the Binding Update according to the following tests:
> 
>     -  The packet MUST contain a Home Address option with a unicast
>        routable home address, unless the Source Address is the home
>        address of the mobile node

a binding ack with code 139 makes no sense here. ICMP param problem
I think is more appropriate. or discard is even better.

>     -  The Header Len field in the Mobility Header is no less than the
>        length specified in Section 6.1.7.

ICMP param problem is the only one that make sense here.

> 
>     -  The Sequence Number field in the Binding Update is greater than
>        the Sequence Number received in the previous Binding Update for
>        this home address, if any.

we have bind ack code 135 for this.

> 
>    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:
> 
>     -  A Nonce Indices mobility option MUST be present, and the Home and
>        Care-of Nonce Index values in this option MUST be recent enough
>        to be recognized by the correspondent node.

we have codes 136, 137 and 138.

>    When using Kbm for validating the Binding Update, the following are
>    required:
> 
>     -  The Binding Authorization Data mobility option MUST be present,
>        and its contents MUST satisfy rules presented in Section 5.2.6.
>        Note that a care-of address different from the Source Address MAY
>        have been specified by including an Alternate Care-of Address
>        mobility option in the Binding Update.  When such message is
>        received and the return routability procedure is used as an
>        authorization method, the correspondent node MUST verify the
>        authenticator by using the address within the Alternate Care-of
>        Address in the calculations.

is 139 to be used here? we used to have silent discard before. I dont
know how the MN can send BUs to a CN without the Binding Authorization 
Data mobility option. silently discard seems to be perfect for this.

>     -  The Binding Authorization Data mobility option MUST be the last
>        option and MUST NOT have trailing padding.

ICMP param problem. infact we process this.

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

ofcourse. ignore the (H) bit. or 133 (Not home agent for this mobile
node).

comments???

when exactly should 139 be used?

regards
Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Dec 2002 14:20:06 +0200

> but now, the CN is also required to do that???

Draft 19 Section 9.5.4 lists the conditions when to send a BA.
Rejected BU is one such case.

> I think is more appropriate. or discard is even better.

We got a discard already based on the 9.5.1 and 9.5.4 text.

> ICMP param problem is the only one that make sense here.

Hmm... I agree in a way, but I hate to put in several different
response messages based on what the problem was.

> we have bind ack code 135 for this.

Current text is fine for this.

> we have codes 136, 137 and 138.

Current text is fine for this too.

> Data mobility option. silently discard seems to be perfect for this.

This is perhaps something that could be argued about. I guess Thomas
was after systematic errors, e.g. something wrong with your implementation's
algorithms. I don't see a problem in adding a status return for this; in any
case the security danger is not going to be any worse than spoofed <something>.

> ICMP param problem. infact we process this.

See above.

> ofcourse. ignore the (H) bit. or 133 (Not home agent for this mobile

I removed this rule based on Brian's comments.

> when exactly should 139 be used?

I guess Thomas was worried that we are using silent discard in too eager
way, and it could be helpful to send back responses in some cases. I don't
care that much either way, but I'd like to get the spec finished and agreed
even by the ADs. Based on my analysis, I'd like to avoid any responses for
[HC]oT{,I} messages but on BUs the responses may in some cases make sense,
at least in terms of being able to tcpdump and see that my box (or the peer's)
is not agreeing. Not a huge benefit, but not a lot of cost either. However,
I'd like to avoid the pain of specifying when to send several different kinds of
messages (Param Problems, BEs, and BAs). So that's why the proposal was to use
BA Status codes.

So the my proposal is still that 139 be introduced and cover header len
and BAD problems. [If you feel strongly about this, maybe we could use
ICMPs instead for the header length, or even BEs. In fact BEs might make
more sense given that we already deal with one header problem (MH Type
unrecognized) using BEs.]

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Tue, 10 Dec 2002 11:06:20 -0500

My $0.02

> We got a discard already based on the 9.5.1 and 9.5.4 text.

Agree.

> response messages based on what the problem was.

The ICMP param problem would make the handling of this header the
same as all the other exetension headers.

> Current text is fine for this.

Agree.

> Current text is fine for this too.

Agree.

>> Data mobility option. silently discard seems to be perfect for this.

I thought that we had a "Invalid BAD" before which was extended to
"Invalid or missing BAD" and then removed from the draft.

> case the security danger is not going to be any worse than spoofed 

I am leaning towards silent discard for the missing BAD.

>> ICMP param problem. infact we process this.

I like the ICMP error a little better in this case then a BA or BE.

> unrecognized) using BEs.]

The thing is, most other header processing already handles header length
and option position errors with ICMP.  I think we should continue this
practice.  So, general errors, like the header length (too short/too long),
option positioning, option lengths (too short/too long) are already covered
by ICMP.  Mobility specific errors that deal with the actuall contentent of
the mobility message need a mobility error code.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Dec 2002 01:35:44 +0200

> the mobility message need a mobility error code.

Ok. Let's use the ICMP then for this purpose too. Do you wish to signal
a failure with BAD using s Status code or not at all? Yes, I remember now
that we're cycling through the same discussions... perhaps we should stick
with the earlier consensus on not signaling it?

Jari

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 11 Dec 2002 09:05:50 -0500

> with the earlier consensus on not signaling it?

Not signaling invalid/missing BAD is fine by me (I think that was prior
agreement).

-vlad