Subject: [Int-area] A few more topics on the list to be discussed at the SeND & CGA Extensions BOF

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 28 Jun 2007 17:26:30 +0200

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

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

Eric Levy-Abegnoli  

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 28 Jun 2007 14:28:12 -0700

that came up during a thorough analysis of 3971 and 3972. Is the intention 
of

jak>> Yes, I think that is the main point of restarting the WG.

know, the source address does not have to equal the target address. So 
anyone

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.

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

jak>> If it was unclear to you while implementing it, it sounds like it 
needs to be updated.

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.

                        jak

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 29 Jun 2007 10:19:26 +0200

On Thursday 28 June 2007 11:28 pm, James Kempf wrote:
> 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
> - 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
> 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.
> 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 
agree
> 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).
>
> 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
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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 29 Jun 2007 15:10:56 -0700

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:

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-masked]]
Sent: Fri 6/29/2007 1:19 AM
To: James Kempf
Cc: [email-masked]; INT Area
Subject: Re: [CGA-EXT] A few more topics on the list to be discussed at the SeND& CGA Extensions BOF

agree