Subject: [Mip6] Ambiguity about handling invalid mobility options in RFC 3775

From: Ville Nuorvala <[email-masked]>
Date: Tue, 21 Mar 2006 19:36:22 +0200

Hello,

I think just encountered an ambiguity in the MIPv6 that hasn't been 
covered before. This happened when testing my NEMO implementation NEPL, 
against the TAHI NEMO HA conformance test version 0.9.0, but the issue 
is in no way NEMO specific.

The NEMO test just happens to check for things the MIPv6 test doesn't, 
otherwise this issue would probably have been raised by someone earlier.

The question is: What should a MIPv6 implementation do when receiving an 
invalid or malformed Mobility Option?

The TAHI test sends out BU messages with Mobile Network Prefix Options 
that are of an invalid length (either too long or too short) and expects 
an ICMPv6 Parameter Problem message as a response.

As I haven't been able to find any rule covering this case in neither 
RFC  3775 nor RFC 3963, I'm mot yet convinced this is the (only) correct 
behavior.

I skimmed through the Neighbor Discovery specification (RFC 2461) to see 
if it could provide me with a precedent w.r.t. the Neighbor Discovery 
options, but that was unfortunately not the case.

As far as I can see, there are quite a number of alternatives available:

1) Send an ICMPv6 Parameter Problem message.

This is one logical solution as RFC 3775 section 9.2 proposes a similar 
approach for checking the Mobility Header length. There are however some 
major problems with this approach.

NEPL and MIPL 2, which NEPL is based on, uses a userspace daemon for the 
MIPv6 signaling. Our implementation, as well as any other userspace 
implementation will be unable to receive the whole packet intact from 
the OS kernel which makes it extremely hard to generate the payload data 
for the ICMPv6 error message from within userspace.

In practice this means the Mobility Options must be parsed in the 
kernel. This however means the kernel code must be updated each time a 
new Mobility Option is defined to ensure the kernel is able to parse it 
properly. This in turn is against the principle in RFC 3775 to just 
ignore any unrecognized Mobility Options.

2) Silently discard a message with invalid Mobility Options.

This solution is easy to implement and is in line with the way we handle 
an incorrectly placed Binding Authorization Data in RFC 3775 sections 
9.5.1 and 11.7.3.

In this approach the offending node doesn't get any notification from 
the receiver, but I'm not sure that really matters. There are also 
several other error cases where we just silently discard the incoming 
packet without notifying the sender. It is also debatable whether a node 
sending malformed packets gains anything by receiving an error message 
from the receiver.

3) Skip invalid Mobility Options.

This is easy to implement, but I'm not sure if finding a malformed 
Mobility Option is the same as not understanding it (RFC 3775 setion 6.1)

4) Send BA status >= 128.

This is also easy to implement, but doesn't fix the whole problem as it 
only covers receiving a malformed BU.

5) Define new BE type.

This is definitely not preferable as it isn't backwards compatible, but 
I just added it for completeness sake. I'd just like to ask why an 
unspecified or generic BE message type wasn't defined reserved for new 
or unexpected error situations like this?

I hope the authors of the MIPv6 specification can shed some light on the 
subject or that the WG can come to some sort of consensus about the 
proper way to handle this problem.

Best regards,
Ville Nuorvala

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Brian Haley <[email-masked]>
Date: Tue, 21 Mar 2006 14:42:30 -0500

Hi Ville,

> invalid or malformed Mobility Option?

Can you be more specific as to what this test is sending?  Is the actual 
packet length too short/long, or what the header says is there?

> options, but that was unfortunately not the case.

This might be covered by Section 3.4 of 2463:

    If an IPv6 node processing a packet finds a problem with a field in
    the IPv6 header or extension headers such that it cannot complete
    processing the packet, it MUST discard the packet and SHOULD send an
    ICMPv6 Parameter Problem message to the packet's source, indicating
    the type and location of the problem.

-Brian

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Tue, 21 Mar 2006 11:57:56 -0800

hi Ville,

the right solution would be to send an ICMP
parameter problem.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Mar 2006 21:59:31 +0100

In your previous mail you wrote:

   
=> but as the Mobility Header is not really an extension header does this
apply?

Regards

[email-masked]

---

From: Brian Haley <[email-masked]>
Date: Tue, 21 Mar 2006 16:16:09 -0500

> => but as the Mobility Header is not really an extension header does this

It's not?  RFC 3775 says otherwise:

6.1.  Mobility Header

    The Mobility Header is an extension header used by mobile nodes,
    correspondent nodes, and home agents in all messaging related to the
    creation and management of bindings.  The subsections within this
    section describe the message types that may be sent using the
    Mobility Header.

-Brian

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Mar 2006 22:37:03 +0100

> => but as the Mobility Header is not really an extension header does this
   
   It's not?

=> it is not: it has the right format so it will be easy to change it
to an extension header but today it is not (next-header field value is
locked for instance).
BTW IMHO to use the ICMPv6 parameter problem is still the best.

Regards

---

From: Brian Haley <[email-masked]>
Date: Tue, 21 Mar 2006 16:51:43 -0500

> BTW IMHO to use the ICMPv6 parameter problem is still the best.

Francis,

Nowhere in 2460 does it say an extension header can't be terminal, 
you're not being liberal in what you accept for the definition :)

And I agree, ICMPv6 param problem is the best solution.

-Brian

---

From: Ville Nuorvala <[email-masked]>
Date: Wed, 22 Mar 2006 14:08:58 +0200

Brian Haley wrote:
>> covered before. This happened when testing my NEMO implementation 
>> NEPL, against the TAHI NEMO HA conformance test version 0.9.0, but the 
>> issue is in no way NEMO specific.
>>
>> The question is: What should a MIPv6 implementation do when receiving 
>> an invalid or malformed Mobility Option?
> 

The packet is otherwise ok except for the malformed Mobile Network 
Prefix Option. The correct length of the option is 18 octets, but in one 
test it's one octet too short, in another it's one octet too long.

>> that are of an invalid length (either too long or too short) and 
>> expects an ICMPv6 Parameter Problem message as a response.
>>
>> RFC  3775 nor RFC 3963, I'm mot yet convinced this is the (only) 
>> correct behavior.
>>
>> I skimmed through the Neighbor Discovery specification (RFC 2461) to 
>> see if it could provide me with a precedent w.r.t. the Neighbor 
>> Discovery options, but that was unfortunately not the case.
> 

Ok, although my thoughts about the true nature of the MH are similar to 
Francis'es, I guess the above rule will apply as RFC 3775 *does* define 
the MH as an extension header.

With the extension header assumption, I just think the handling of 
unrecognized MH types is quite odd. What was the rationale behind 
defining the BE status 2 message when an ICMPv6 Parameter Problem 
message with the pointer set to the MH type field would have worked just 
as well?

Regards,
Ville

---

From: Brian Haley <[email-masked]>
Date: Wed, 22 Mar 2006 11:27:58 -0500

>> Can you be more specific as to what this test is sending?  Is the 
>> actual packet length too short/long, or what the header says is there?
> 
> 

It doesn't look like 3963 is as clear as 3775 when it comes to 
processing headers and options, maybe you should bring this up on the 
nemo list (or issue tracker?) as something to be fixed when it's updated.

> message with the pointer set to the MH type field would have worked just 

I don't remember exactly, but my guess is a BE says "I do mobility, but 
don't know what this is", ICMPv6 says "I don't know what this is".

-Brian

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Wed, 22 Mar 2006 08:43:22 -0800

> message with the pointer set to the MH type field would have worked just

you are right. ICMP parameter problem would have
worked too. I don't remember now why we added
Binding Error status 2.

Vijay

---

From: Keiichi SHIMA <[email-masked]>
Date: Wed, 22 Mar 2006 14:50:39 -0600 (CST)

From: Brian Haley <[email-masked]>
Subject: Re: [Mip6] Ambiguity about handling invalid mobility options in RFC 3775
Date: Wed, 22 Mar 2006 11:27:58 -0500
> don't know what this is", ICMPv6 says "I don't know what this is".

I also don' remember the discussion exactly, but, one possible
scenario the list discussed was e.g. to support a new RO mechanism.

Suppose we define new type numbers for the new RO mechanism in the
future.  A mobile node tries to use the new messages, but the node
communication to does not support it.  The mobile node can fall back
if the correspondent node sends a BE with status 2.  If the mobile
node receives ICMPv6 err, maybe the mobile node stops mobility
signaling procedure.

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
WIDE Project <[email-masked]>