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:
> -----Ursprüngliche Nachricht-----
> Von: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] Im Auftrag von
> Brian Haley
> Gesendet: Mittwoch, 27. Mai 2009 04:57
> An: Charles E. Perkins
> Cc: mext
> Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding
> errors"], part 2 of 3: "Receiving ICMP Errors"
> 
> Hi Charlie,
> 
> Charles E. Perkins wrote:
>> Hello folks,
>>
>> Last month, issue #18 showed up without any fanfare on the
>> issues tracker list:
>>    http://trac.tools.ietf.org/wg/mext/trac/ticket/18
>> I'd like to initiate discussion on the points raised as part
>> of issue #18.  There are three main points, which can be
>> discussed separately.  In this note, I transcribe the
>> discussion about the second of the three points.
>>
>> =============================================
>>
>> 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?

> 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