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.
- 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.
- 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.
jak
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
