Subject: Re: [MEXT] [mext] #18: Subject: Issues regarding Home Address Option & ICMP / Binding errors

From: "Mext Issue Tracker" <[email-masked]>
Date: Mon, 29 Jun 2009 23:16:34 -0000

#18: Subject: Issues regarding Home Address Option & ICMP / Binding errors
----------------------------------------+-----------------------------------
 Reporter:  [email-masked]             |        Owner:  [email-masked]
     Type:  defect                      |       Status:  assigned             
 Priority:  major                       |    Milestone:  IETF75               
Component:  draft-ietf-mext-rfc3775bis  |      Version:  4.0                  
 Severity:  Active WG Document          |   Resolution:                       
 Keywords:  Home Address Option         |  
----------------------------------------+-----------------------------------
Changes (by [email-masked]):

  * keywords:  => Home Address Option
  * owner:  => [email-masked]
  * version:  => 4.0
  * status:  new => assigned
  * milestone:  => IETF75

Comment:

 I propose to resolve
 this issue by accepting the suggested text, which should
 not materially impact any compliant implementations.

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

 The issue (and proposed resolution):

 >> In Section 9.3.1. Receiving Packets with Home Address Option:
 >> "Packets containing a Home Address option MUST be dropped if
 >> there is no corresponding Binding Cache entry. (...) These
 >> tests MUST NOT be done for packets that contain a Home Address
 >> option and a Binding Update."
 >>
 >> The second part of this statement (packets that contain a Home
 >> Address option and a Binding Update) requires looking ahead in
 >> the packet for a Mobility Header with a respective type. This
 >> action is stricly forbidden by IPv6  ...

 >>        ..........     Changes to the second paragraph in 9.3.1:

 >> Mobile nodes can include a Home Address destination option in a
 >> packet if they believe the correspondent node has a Binding Cache
 >> entry for the home address of a mobile node. If the Next Header
 >> value of the Destination Option is one of the following: {50 (ESP),
 >> 51 (AH), 135 (Mobility Header)}, the packet SHOULD be processed
 >> normally. Else, the packet MUST be dropped if there is no
 >> corresponding Binding Cache entry. A corresponding Binding Cache
 >> entry MUST have the same home address as appears in the Home Address
 >> destination option, and the currently registered care-of address
 >> MUST be equal to the source address of the packet.

 >> The assumption about looking ahead in the packet is not correct, I've
 >> implemented this without doing it  :)   Since a HAO isn't mandatory in
 all
 >> BU's (deletion for example), that processing code just needs to know if
 >> one was seen previously - if not the packet could be silently dropped.
 >>

 The response from Brian Haley points out that the processing
 can be done without violating this restriction:

 >> 1. When processing the HAO, you need to do a binding cache lookup to
 >>    validate it.  You can "remember" whether you found an entry, and
 whether
 >>    you swapped the address.  You need to continue to process it...
 >>
 >> 2. When processing the MH, you can consult the saved saved information
 from
 >>    step #1 - did I see a HAO?

 but then subsequently agrees with the proposed modification to section
 9.3.1:

 >> I think the <... proposed text ...>
 >> ... is fine.  I don't think any other next header types would be valid.

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

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/mext/trac/ticket/18#comment:1>
mext <http://tools.ietf.org/wg/mext/>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jun 2009 10:24:44 +0200

Please express your opinion on this before the sunday 5th of july.
We hope to close the issue then and afaiu, we will have closed all the 
issues and we will be ready for WGLC

Thanks, marcelo

---

From: "Mext Issue Tracker" <[email-masked]>
Date: Tue, 30 Jun 2009 18:01:04 -0000

#18: Subject: Issues regarding Home Address Option & ICMP / Binding errors
----------------------------------------+-----------------------------------
 Reporter:  [email-masked]             |        Owner:  [email-masked]
     Type:  defect                      |       Status:  closed               
 Priority:  minor                       |    Milestone:  IETF75               
Component:  draft-ietf-mext-rfc3775bis  |      Version:  4.0                  
 Severity:  Active WG Document          |   Resolution:  fixed                
 Keywords:  Home Agent Binding Error    |  
----------------------------------------+-----------------------------------
Changes (by [email-masked]):

  * keywords:  Home Address Option => Home Agent Binding Error
  * priority:  major => minor
  * status:  assigned => closed
  * resolution:  => fixed

Comment:

 >> In Section 11.3.6. Receiving Binding Error Messages, it is not
 >> considered that Binding Error Messages can also come from Home
 >> Agents when acting as a Correspondent Node to its Mobile Nodes
 >> [see also issue #12].   .........

 >> If the Correspondent Node is the Home Agent, it is likely that
 >> there is also no tunnel to route communications through. This
 >> case may happen if the Home Agent reboots without a persistent
 >> storage of its Binding Cache.

 Scenario for failure case:

   * Suppose the MN has successfully bound to its HA.

   * Now the HA crashes, losing all of its Binding Cache and Tunnel
     information. This means that the Tunnel to the MN is now invalid. Any
     further packets sent thru the tunnel will be dropped at the HA.

   * The MN now starts a direct communication with the HA. (e.g. the user
 pings
     the HA to check if it's alive). As the MN still has a Binding Update
 List
     entry with the corresponding addresses, it will add a HAO to the
 packet and
     send it directly to the HA.

   * Upon reception, the HA checks the HAO and will not find a matching
 Binding
     Cache entry and return a Binding Error.

   * According to 11.3.6, the MN should now use the Tunnel, which is still
     invalid.

 Proposal: Add the following as the first bullet in section 11.3.6:

 >>  o If the Binding Error Message was sent by the Home Agent,
 >>    the Mobile Node SHOULD send a Binding Update to the Home Agent
 >>    according to Section 11.7.1.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/mext/trac/ticket/18#comment:2>
mext <http://tools.ietf.org/wg/mext/>

---

From: "Mext Issue Tracker" <[email-masked]>
Date: Tue, 30 Jun 2009 18:18:43 -0000

#18: Subject: Issues regarding Home Address Option & ICMP / Binding errors
----------------------------------------+-----------------------------------
 Reporter:  [email-masked]             |        Owner:  [email-masked]
     Type:  defect                      |       Status:  reopened             
 Priority:  minor                       |    Milestone:  IETF75               
Component:  draft-ietf-mext-rfc3775bis  |      Version:  4.0                  
 Severity:  Active WG Document          |   Resolution:                       
 Keywords:  ICMP Parameter Problem      |  
----------------------------------------+-----------------------------------
Changes (by [email-masked]):

  * keywords:  Home Agent Binding Error => ICMP Parameter Problem
  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

 Receiving ICMP Errors [Fabian Mauchle <[email-masked]>]

 Proposed resolution: do not make any changes to existing specification
 in response to this issue regarding handling of ICMP Parameter Problem

 Issue #18, part 2 of 3:

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

 Three discussion points [Brian Haley <[email-masked]>]:

 >> What do to with ICMP Parameter Problem, Code 0  ...?

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

 and:

 > 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

 and:

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

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/mext/trac/ticket/18#comment:3>
mext <http://tools.ietf.org/wg/mext/>