Source==target is not part of generic ND (RFC 2461). It is an implicit part of
SEND (RFC 3971) in that RFC 3971 disallows proxies (see Section 1, Paragraph
7). But this should have been more explicitly stated. The case you mention
(sourcing under link local with global as the target) wasn't even considered
when we did the original spec, but I can see why people might want to do it.
Clearly, the host isn't proxying the target since it owns the link local. I
agree that these cases should be clarified if the WG is restarted. These kind
of implementation twitters are the exactly kind of thing that the WG needs to
address.
My point about the CPS is that it is requesting information. Every node on the
link has the right to request that information, regardless. CPS does not have
a semantic that involves requring it to prove a claim of authorization to
operate on an address. Therefore, requiring a CGA and signature doesn't make
sense to me. For the CPA, though, it might make sense since the receiver might
want to know that it did, indeed, come from a certified router, as we
discussed.
I don't understand this point:
I am concerned by IP extensions which might not be something common in root
cert authority certificates for some time. So either you consider this part
"very" optional, but that does not seem to be the spirit of 3971. Or hosts
must get a certificate from a more specialized cert authority.
BTW some hosts (printers, fax, ...) don't run a browser.
I am also concerned about host access to CRL, which might be more critical if
IP extensions triger more frequent certificate invalidations.
It sounds like you are worried about the cert extensions for prefixes, right?
3971 doesn't require this. As a practical matter, I think the value of getting
the certs validated by a proxy able to handle the IP extension and getting that
information securely to a host would be minimal beyond just simply deploying a
cert without the IP extensions and letting the host do it, due to the
complexities involved in setting up and verifying trust between the three
entities.
jak
________________________________
From: Eric Levy-Abegnoli [mailto:[EMAIL PROTECTED]
Sent: Fri 6/29/2007 1:19 AM
To: James Kempf
Cc: [EMAIL PROTECTED]; INT Area
Subject: Re: [CGA-EXT] A few more topics on the list to be discussed at the
SeND& CGA Extensions BOF
On Thursday 28 June 2007 11:28 pm, James Kempf wrote:
> Coming late, hope not too late ...
> Having implemented SEND on the router side, there are a few
> issues/questions that came up during a thorough analysis of 3971 and 3972.
> Is the intention of
> the BOF to go through that type of experience, and eventually
> generate/trigger an update of 3971?
>
> jak>> Yes, I think that is the main point of restarting the WG.
>
> For examples (these are just a few substantial):
> - 3971 mandates the CGA address to be the source address for NA. As far as
> I know, the source address does not have to equal the target address. So
> anyone
> could claim someone else (target) address as long as it does that with a
> valid CGA source address. Protection against address spoofing sounds a bit
> bogus, doesn't it? Or I am missing something? Shouldn't we change that to
> protect the target address instead?
>
> jak>> RFC 3971 does not apply to proxy ND so the source and target address
> must be the same. This could probably have been made clearer. If the WG is
> formed and proxy ND is supported, then this would need to be changed. In
> any case, the target address must be a CGA.
Can you tell me which RFC mandates the source to equal the target? Reading
2461, the source can be any address on the interface. For link-locals,
because of the scope preference, they are likely to be the same, but for
global (targets), source could be any global on the link. In fact, I know
implementations that will source NS with a link-local, even to query global
target, so the NA will also be sourced with a link-local, different from the
target.
>
> - CPS/CPA are not protected with the SEND options (nonce, timestamp, cga,
> rsa). Why not? It sounds strange to have created a bunch of new options to
> protect old messages, and ignore these for these two. I could not find in
> the
> archive any discussion that would explain the omission.
>
> jak>> CPS is requesting a certificate chain, what is the attack?
What is the attack with RS? NS ? Is it just because they can carry slla ?
They might not carry it (it's a "SHOULD" for unicast in 2461), hence my
confusion ...
> CPA is
> sending one. I guess the attacker might be able to obtain a legitimate
> certificate, advertise itself as a router, then provide a verifable cert
> chain when the victim requested it. This is a problem in hotspot networks
> that use UAM too. But putting the SEND options on the CPA isn't going to
> help here. The receiving node would need to verify the identity of the
> router certificate ("is 'Joe's FlybyNight IP Service' an ISP that I want to
> trust?"). All the cert chain verification tells you is that the public key
> is certified by the parent cert authority.
agree
>
> - It's a bit unclear what you have to do with regard to nonces, when
> multicasting advertisements (RA) after receiving a bunch of solicitations
> (RS). In fact 3971 suggest it's broken. My interpretation is that we can
> accumulate all nonces received in RS, and insert all of them in the one RA.
> Should we clarify this?
>
> jak>> If it was unclear to you while implementing it, it sounds like it
> needs to be updated.
>
> On the front of new topics, beside the one listed by others (that we would
> definitely interested to work on), one extra came up during internal and
> external discussions. Could we come up with some "transitionning"
> mechanism that would enable some third party node (could be the router,
> switch, or external server) to validate router credentials on behalf of
> hosts which don't want to/can't be part of the PKI? The hard part of course
> is to signal the result to the host (not sure there is a good solution to
> that problem).
>
> jak>> Any host running a general operating system these days has a browser
> on it with access to a cache of root cert authority certificates. Most
> operating systems even manage those certs independently of the browser. So
> unless you are talking about an application like sensor networks or
> something like that, I have some difficulty seeing why requiring that the
> host perform certificate validation would be a burden. The host doesn't
> have to be part of the PKI, it just needs to have a certificate cache. The
> protocol was specifically designed like TLS so that the host didn't need to
> be provisioned with a certificate.
I am concerned by IP extensions which might not be something common in root
cert authority certificates for some time. So either you consider this part
"very" optional, but that does not seem to be the spirit of 3971. Or hosts
must get a certificate from a more specialized cert authority.
BTW some hosts (printers, fax, ...) don't run a browser.
I am also concerned about host access to CRL, which might be more critical if
IP extensions triger more frequent certificate invalidations.
Eric
>
> jak
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
