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

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 26 May 2009 10:04:53 -0700

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,..."

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.

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.

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

Please submit comments on the above discussion and proposal.
If consensus is reached soon, I will incorporate the consensus
text in a revision of rfc3775bis to be released before the next
IETF.

Regards,
Charlie P.

---

From: Brian Haley <[email-masked]>
Date: Tue, 26 May 2009 22:56:54 -0400

Hi Charlie,

> discussion about the second of the three points.

This text seems to be referring to Section 11.3.5. - Receiving ICMP Error
Messages, not 11.3.6.

>     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.

>     If the source of the ICMP error message is a Home Agent,

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

---

From: Fabian Mauchle <[email-masked]>
Date: Wed, 27 May 2009 15:41:28 +0200

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 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,

>     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.

>     If the source of the ICMP error message is a Home Agent,

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?)
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.
Maybe using IPsec ESP also for the ICMP traffic between the MN and HA would
help?

Fabian

---

From: Brian Haley <[email-masked]>
Date: Wed, 27 May 2009 14:30:16 -0400

> on the traffic to reply with this "fake" ICMP while there's an outstanding

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.

> 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

But this is a failure before processing the Mobility Header, so I think
following RFC 4443 rules applies.

-Brian

---

From: Fabian Mauchle <[email-masked]>
Date: Thu, 28 May 2009 09:40:49 +0200

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Brian Haley
Gesendet: Mittwoch, 27. Mai 2009 20:30
An: Mauchle Fabian ([email-masked])
Cc: 'mext'
Betreff: Re: [MEXT] Issue #18 ["Home Address Option & ICMP / Binding
errors"], part 2 of 3: "Receiving ICMP Errors"

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.

------------------------------------

-Brian
------------------------------------

I can' quite follow you. I was thinking of securing all Binding traffic
(Binding Update and any method of error reporting including ICMP)

Fabian

---

From: Brian Haley <[email-masked]>
Date: Thu, 28 May 2009 11:09:27 -0400

>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?

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

---

From: Fabian Mauchle <[email-masked]>
Date: Fri, 29 May 2009 09:31:38 +0200

-----Ursprüngliche Nachricht-----
Gesendet: Donnerstag, 28. Mai 2009 17:09

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