Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#27 closed defect (fixed)

Broken security procedure for DAD

Reported by: julien.ietf@… Owned by: julien.ietf@…
Priority: major Milestone:
Component: draft-ietf-netlmm-mn-ar-if Severity:
Keywords: Cc: netlmm@…


MN-AR interface spec does not specify correctly the security procedure for addresses duplicates happening on different links.

Proposed Resolution: Specify that the AR should proxy a DAD NS sent by a MN up to the MAP for checking address duplicate status. If there is a duplicate registered at another AR, the MAP SHOULD proxy this DAD NS up to the AR where the duplicate occurs. This AR will send the proxy NS to get a signed NA from the colliding MN. The signed NA is in turn forwarded back to the MN doing DAD via MAP and AR. Hence the initial AR can securely defend the duplicate address on behalf of the other MN by sending the signed proxy NA.

Change History (4)

comment:1 Changed 13 years ago by julien.ietf@…

  • Cc netlmm@… added

comment:2 Changed 13 years ago by julien.ietf@…

  • Cc netlmm@… added; netlmm@… removed
  • Status changed from new to assigned

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

comment:3 Changed 13 years ago by julien.ietf@…

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:4 Changed 12 years ago by anonymous

  • Milestone milestone1 deleted

Milestone milestone1 deleted

Note: See TracTickets for help on using tickets.