Pasi Eronen and Valtteri Niemi write: Overall, our biggest complaint about this document is that it seems the use of certificates instead of CGAs for Neighbor Discovery (not Router Discovery) is not really thought out yet. We believe the document would probably be significantly easier to understand and analyze if the CGA case was described separately from the non-CGA case. This could mean splitting to two separate documents, or at least to separate sections within one document (consider such a split especially for sections 4 and 8). ----------- Jari Arkko responds: I agree that ND cert usage is less baked than the rest of the spec. Regarding the split, the CGA and Signature options that I outlined in draft-send-ndopt.txt might help the situation as well. ----------- IETF-57 minutes: Complaint: not well thought out. The authors agree. The authors proposal, based on new information about IPRs, to remove the text of using certificates for ND; just rely on CGA. ND certificates could be added as an extension later. Francis Dupont: Don't believe dropping ND certificates is a good idea. CGA does not provide the same properties. Jari: With certificates, can also ensure this node is a member of this company, etc. Agreed. Michael Richardson: Don't think I understand your proposal. Is it to say I will use a CGA address signed by key, but PK is not authorized by CA. (yes.) I rather we went forward quickly, but I am concerned that req for retrieving cert chains may be significant chain to state machines and operational pieces. Might find ourselves in a bad situation in the future because it may be hard to add later. Jari: Yes, but for discovering routers, we would still use certificate discovery. Just drop it for NS & NAs for now. Rick A.?: Isn't is straight-forward to add a capability in hosts to say no, I don't have a certificate chain. Because you should provide trust chain, but you can give a simple NAK. I don't have a trust chain to give you. At least you know that you got a response. Jari: Current spec has some aspects of that. But some details have not been fully thought out. It's a little tricky with addressing, before ND is complete. Pekka: More practical problem is that we'd like to advance draft, and current text is not specific enough. We'd like to leave it out for now. If anyone in room would like to rewrite? Otherwise we would like to take out. Rick: I'm willing to work on text, either for WG draft or parallel draft. James: Issues with certificate interoperability as well. Pekka Savola: We have to consider scenario where this would give additional protection. Where layer 2 or lower has not authentication to network. So what is the applicability? Pasi Eronen: Agree with chairs that it should be dropped now. Current spec does not say how it should work. So there is no section in draft to remove. James: Some L2 protocols provide certified MAC address. That would be ideal situation for SEND. But Cable Licensing? is only L2 protocol that does that. The WG decision was to remove the ND certificate facility for now. However, if someone (Rick?) produces a separate draft on that, it can be accepted as a WG item. ----------- Pekka Nikander: The WG agreed at the Vienna meeting that the usage of certificate chains for ND (as opposed to RD) should be left for future study. At the same time, some people voiced their opinion that such a feature might be very useful, and I think that at least someone even volunteered to write a spec. However, so far we (the chairs) haven't seen any concrete results. Anyway, I have now went through the current working version of the draft, and tried to carefully mark any locations that talk about certificates and ND as for further study. I can't promise that I have caught all such locations, though. Hence, some more reading is probably needed. A snapshot (rough at cert formats) of the draft is available at the following URLs: http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct14.txt http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct14.html http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-ndopt-00-pre-Oct14.xml Anyway, I think this issue is now closed. -----------