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 protected] https://www1.ietf.org/mailman/listinfo/int-area
