[Int-area] Re: [netlmm] RE: Multilink subnet issues and proxy/relay DAD

["James Kempf" <[e-mail]>]

Julien,

Yes, multikey CGAs would solve the problem. Each router has its own private 
key used to sign, the CGA is generated using multiple keys, and the 
signature is validated using multiple public keys.

But that would require a modification to SEND.

            jak

----- Original Message ----- 
From: "Julien Laganier" <[e-mail]>
To: "Templin, Fred L" <[e-mail]>
Cc: <[e-mail]>; "Dave Thaler" <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Monday, November 06, 2006 5:06 PM
Subject: Re: [netlmm] RE: Multilink subnet issues and proxy/relay DAD


> Hi Fred,
>
> On Monday 06 November 2006 16:51, Templin, Fred L
> wrote:
>>
>> This all sounds good, but in terms of a node moving
>> between routers on p2p links I have seen some
>> proposals that all routers would configure the same
>> LL address thereby avoiding collisions after an
>> initial DAD test with the first router. (I guess
>> that wouldn't be appropriate for shared links, since
>> there couldn't be multiple routers on the link with
>> the same LL address?)
>
> AFAICS, mandating that on every link of the domain the
> same set of LL addresses is configured on the set of
> on-link routers would avoid problem when multiple
> routers are on-link.
>
>> Is there a problem with assigning the same LL
>> address to different routers whereby that shouldn't
>> be done and we need proxy/relay-DAD instead?
>
> There is a problem with the current SEND because that
> would require to share the same public key amongst
> those routers, and hence sharing the same private key
> as well. That wouldn't be good from a security point
> of view.
>
> A solution exists if SEND is updated to support CGAs
> derived from multiple keys, or even ring signatures
> [1] in which multiple keys could be used to generate a
> CGA, each key being used by one router only.
>
> --julien
>
> draft-kempf-mobopts-ringsig-ndproxy
> <http://www.watersprings.org/pub/id/draft-kempf-mobopts-ringsig-ndproxy-02.txt>
>
>> -----Original Message-----
>> From: Julien Laganier
>> [mailto:[e-mail]] Sent: Monday,
>> November 06, 2006 3:59 PM
>> To: [e-mail]
>> Cc: Templin, Fred L; Jari Arkko; [e-mail];
>> Dave Thaler; [e-mail]; [e-mail];
>> [e-mail] Subject: Re: [netlmm] RE: Multilink
>> subnet issues and proxy/relay DAD
>>
>> Fred,
>>
>> My follow-up inlined below,
>>
>> On Monday 06 November 2006 14:55, Templin, Fred L
>>
>> wrote:
>> > Jari - see below for follow-up:
>> > > Hi Fred,
>> > >
>> > >>   1. What are the issues wrt proxy/relay DAD
>> > >> that would interfere with its adoption as a
>> > >> standard mechanism?
>> > >
>> > > Almost anything can be made to work, but often
>> > > the question is what works best or with least
>> > > changes. In particular, we can make proxy DAD
>> > > work, probably even with SEND. But I would
>> > > still prefer an approach that does not require
>> > > that. Also, if you need proxy DAD, does that
>> > > mean that link local multicast does not work
>> > > on the link as expected?
>> >
>> > The question is coming from the context of what to
>> > do about two nodes connected to different links
>> > that configure colliding addresses and then move
>> > onto the same link at some later point in time. It
>> > seems that a pre-service DAD procedure like
>> > proxy/relay DAD would be preferrable to an
>> > in-service DAD, e.g., (re)marking addresses as
>> > tentative and (re)running DAD on link change.
>>
>> Especially since this the default DNA behavior is to
>> not redo DAD when DNA concludes that the link did
>> not change -- because in the NetLMM case the
>> landmark prefix won't change even though the link
>> indeed changed.
>>
>> Regarding the implications on link-local multicast,
>> there's none since there's no change in the
>> communication service model: Normal address
>> resolution isn't impacted by proxy DAD, only NS and
>> NA part of DAD would be proxied when a collision is
>> detected by the NetLMM fabric, otherwise they won't.
>>
>> > [...]
>> >
>> > >>   3. Does the RFC1812 "subnet forwarding model"
>> > >> still apply to IPv6, when there are no IPv6
>> > >> documents that reference RFC1812 normatively?
>> > >>   4. What other non-obvious issues relating to
>> > >> multilink subnets for shared links need to be
>> > >> observed for NETLMM, Autoconf and other
>> > >> contexts?
>> > >
>> > > I am not sure I have an answer. But let me ask
>> > > you a question about something which has been
>> > > unclear to me during the NETLMM discussion. What
>> > > is the real-world functionality that you would
>> > > like to have? Media where this is needed?
>> > > Employing just one prefix per a number of hosts?
>> > > Special requirements on what the scope of link
>> > > local multicast should be?
>> >
>> > Aside from the question of shared prefixes for the
>> > moment, even in just the link-local case the
>> > concern is for nodes that can move within a region
>> > between shared media links on which there may be
>> > neighbors other than just the provider's router.
>>
>> I think the concern apply even when links are
>> point-to-point and the only neighbor to a MN is the
>> provider's router.
>>
>> If a MN happens to move to a link where the router
>> has a colliding link-local address, and the MN
>> doesn't re-run DAD (as per default DNA behavior)
>> then a collision will occur and won't be detected.
>>
>> That's orthogonal to the link type, be it
>> point-to-point or shared, I think.
>>
>> > Proxy/relay-DAD is a pre-service DAD procedure for
>> > ensuring that no two nodes in the region will
>> > configure the same LL address prior to operation.
>> > Another possible method which has been suggested
>> > by James and others is to somehow enforce virtual
>> > point-to-point links as overlays on the shared
>> > media such that the (mobile) nodes would only ever
>> > see their provider's router on the link and no
>> > other neighbors.
>>
>> See my comment above.
>>
>> > Such an arrangement might not be appropriate for
>> > all media types and/or deployments.
>> >
>> > > Also, my understanding of the NETLMM decision
>> > > is that the working group wants to limit initial
>> > > design to per-host prefix model, but that this
>> > > could be extended in the future.
>> >
>> > Well, the relay/proxy-DAD is also about
>> > link-locals; not just non-link-locals configured
>> > from a shared prefix. So, this is somewhat
>> > independent from the per-host prefix question.
>>
>> Agree.
>>
>> > [...]
>>
>> Best,
>>
>> --julien
>
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/netlmm 


_______________________________________________
Int-area mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/int-area