Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP Errors"

[Brian Haley <brian.haley at hp.com>]

Fabian Mauchle wrote:
>>> Receiving ICMP Errors
>>>
>>> Some questions arose whether to treat ICMP Parameter Error messages or
>>> to ignore them. In Section 11.3.6. Receiving Binding Error Messages:
>>> "If the mobile node receives such an ICMP error message (Code 1) in
>>> response to a return routability procedure or Binding Update,..."
>> This text seems to be referring to Section 11.3.5. - Receiving ICMP Error
>> Messages, not 11.3.6.
>>
>>> The following situations are not clear or problematic:
>>>
>>> 1.) If the Mobile Node did not set the Acknowledge bit in the Binding
>>>     Update, should it also accept an ICMP Parameter Problem, Code 1
>>>     and during which period of time?
>>>
>>> 2.) If the ICMP message came from a Home Agent, it is most likely to
>>>     be a spoofed message since packets to the Home Agent nearly always
>>>     contain a Home Address Option, which would cause an ICMP Parameter
>>>     Problem, Code 2 instead. A Mobile Node MUST therefore ignore any
>>>     ICMP Parameter Problem messages originating from a Home Agent,
>>>     otherwise, an attacker could prevent a Mobile Node from sending
>>>     Binding Updates to its Home Agent.
>> What about ICMP Parameter Problem, Code 0?  Those can be sent when either
>> the
>> Payload Proto field or MH header len are invalid, so I'm not sure this
> text
>> is
>> correct.  Home Agent Section 10.2 refers back to Correspondent Node
> Section
>> 9.2,
>> which is where this text is.
>>
>>> Proposal for 2.): Add to the first paragraph in 11.3.6:
>>>     If the source of the ICMP error message is a Home Agent,
>>>     it MUST be ignored.
>> I would agree there could be a problem here, but not with this new text, I
>> think
>> it would actually cause a test failure with the current TAHI tests.  Since
>> the
>> BU to the HA is using IPsec ESP, I'm not sure an attacker will be able to
>> snoop
>> on the traffic to reply with this "fake" ICMP while there's an outstanding
>> BUL
>> entry, will it?
>>
>> -Brian
>> -------------------------------------------
>>
>> What do to with ICMP Parameter Problem, Code 0, is not defined in RFC3775,
>> is it? (Maybe it should be defined?)
> 
> It's defined in RFC 4443:
> 
>    A node receiving this ICMPv6 message MUST notify the upper-layer
>    process if the relevant process can be identified (see Section 2.4,
>    (d)).
> 
> If there isn't anyone to notify then it will be dropped.
> 
> 
>> I think snooping the BU is possible since it is allowed to use a
>> null-encryption algorithm. But even if encryption is used, the IP-header
> and
>> HAO are still transmitted clear.
> 
> But does an attacker know there's a Mobility Header here?
> ------------------------------------
> 
> It will only know if null-encryption is used. But when monitoring a Wireless
> link, the first packet a MN sends with a HAO is very likely to be a BU.

From RFC 3776:

   o  When securing Binding Updates, Binding Acknowledgements, and
      prefix discovery, both the mobile nodes and the home agents MUST
      support and SHOULD use the Encapsulating Security Payload (ESP)
      [3] header in transport mode and MUST use a non-null payload
      authentication algorithm to provide data origin authentication,
      connectionless integrity and optional anti-replay protection.

Null encryption is not allowed according to this.

The question is whether having the MN drop all ICMP param problems from the HA
is better or worse than the very small possibility that someone can disrupt
mobility.  I would vote for leaving the text alone, maybe someone else has an
opinion on this?

> ------------------------------------
>> Maybe using IPsec ESP also for the ICMP traffic between the MN and HA
> would
>> help?
> 
> But this is a failure before processing the Mobility Header, so I think
> following RFC 4443 rules applies.
> 
> -Brian
> ------------------------------------
> 
> I can' quite follow you. I was thinking of securing all Binding traffic
> (Binding Update and any method of error reporting including ICMP)

Section 9.2 covers processing Mobility Headers for all nodes, the third and
fourth checks will send ICMP errors on failure, that's what I was referring to.

Protecting ICMP errors would require new IPsec SPDs, which I don't think is
feasible.

-Brian