Subject: Re: [netlmm] #27: Broken security procedure for DAD

From: netlmm-tracker <[email-masked]>
Date: Tue, 30 May 2006 15:13:36 -0000

#27: Broken security procedure for DAD
-----------------------------------------+----------------------------------
  Reporter:  [email-masked]     |       Owner:  [email-masked]
      Type:  defect                      |      Status:  assigned               
  Priority:  major                       |   Milestone:  milestone1             
 Component:  draft-ietf-netlmm-mn-ar-if  |     Version:  2.0                    
Resolution:                              |    Keywords:                         
-----------------------------------------+----------------------------------
Changes (by [email-masked]):

  * cc:  [email-masked] => [email-masked]
  * status:  new => assigned

Comment:

 Proposed Resolution: Replace Section 2.5 with the text below. It has
 however the implication that each routing update triggered by a DAD-NS
 must encapsulate the entire DAD-NS so that it can be proxied up to the
 colliding MN. Hence, Section 2.1. (MN powers on in a NetLMM domain), 2.2.
 (First attachment of MN moving into a NetLMM domain) and 2.5. (MN
 configuring additional CGAs) would also need to be modified to include the
 encapsulated DAD-NS in the UPDATE message sent to the MAP.

 This is required to insure that the colliding MN will reply with a signed
 NA containing a NONCE picked by the DADing MN. That way the DADing MN will
 accept the NA as per the SEND specification.

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

 2.5.  MN configuring CGA that is in use by another MN in the NETLMM domain

    The access router AR2 learns about new global addresses configured by
    a mobile node MN2 from the NS-DAD message sent by MN2.  When AR2
    sends an UPDATE to the MAP based on this DAD-NS, it also includes the
    entire NS in the message, and waits for a positive acknowledgment
    from the MAP.  If the MAP has an entry for the same CGA with a
    different MNID, it will proxy this DAD-NS up to the access router
    where the duplicate occurs (AR1).  AR1 will then proxy the DAD-NS by
    sending it to the colliding mobile node MN1, and will receive back a
    signed NA from MN1.  AR1 will then forward this signed NA to AR1 via
    the MAP.  At that point, AR2 can securely defend the duplicate
    address on behalf of MN1 by sending to MN2 the signed NA.
 {{{
    MN2       AR2                 MAP               AR1       MN1
     |         |                   |                 |         |
     | NS(DAD) |UPDATE(MNID,CGA,NS)|                 |         |
     |-------->|------------------>| collision(MNID) |         |
     |         |                   |                 |         |
     |         |                   | QUERY[DAD](NS)  | NS(DAD) |
     |         |                   |---------------->|-------->|
     |         |                   | REPLY[DAD](NA)  |  NA     |
     |         |                   |<----------------|<--------|
     |   NA    |REPLY[COLLIDE](NA) |
     |<--------|<------------------|
     |         |                   |

    Figure 8: MN configuring later on a colliding CGA
 }}}

-- 
Ticket URL: <http://www1.tools.ietf.org/wg/netlmm/trac/ticket/27>
netlmm <http://tools.ietf.org/wg/netlmm/>

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm