[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding errors"], part 2 of 3: "Receiving ICMP Errors"
-----Ursprüngliche Nachricht-----
Von: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] Im Auftrag von
Brian Haley
Gesendet: Donnerstag, 28. Mai 2009 17:09
An: Mauchle Fabian (f1mauchl at hsr.ch)
Cc: 'mext'
Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding
errors"], part 2 of 3: "Receiving ICMP Errors"
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.
---------------------------------------
ESP makes a difference between encryption and authentication (See: RFC 4303
Section 3.2). Either one may be null (but not both at the same time). Mobile
IPv6 requires non-null authentication, but there is no statement about
encryption.
Fabian