1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document draft-ietf-send-ipsec-01.txt 57th IETF, Vienna Jari Arkko, Ericsson Research NomadicLab

2 Arkko, 57th IETF: SEND base protocol issue list Issues for discussion here 07 - Cert-only ND protection not thought out 14 - Is CGA-only RD protection useful? 06 - Millisecond time granularity problematic 08 - Certificate details Only if AH is used: 03 - Co-existence scheme flawed due to multicast?

3 Arkko, 57th IETF: SEND base protocol issue list 07 - Certificate-only ND protection Complaint: certificate-only ND protection is “not thought out” –I think we generally agree, this part of the spec is not in as good status as the rest. (What are the specific problems?) Practical proposal: given the new IPR situation, perhaps we should remove certificate-based ND protection completely and rely on CGA only –This would simplify the specification –Can still be added as an extension later

4 Arkko, 57th IETF: SEND base protocol issue list 14 - Is CGA-only RD Protection Useful? Current draft allows CGA-only RD protection CGA tells nothing about your right to be a router Should it be removed? CGA allows to bind the selected default router to Redirects sent by it Other RD-protection might be possible to arrange via heuristics (e.g. the router appears to route) Practical proposal: simplify the draft and just keep the certificate-based RD protection

5 Arkko, 57th IETF: SEND base protocol issue list 06 - Millisecond granularity Current timestamp granularity is one millisecond Can not send two messages within one ms -- normally Ok, but can be problematic in some cases Solutions: –1) Not an issue –2) Allow reception within the same ms; note that getting the same ND message twice is not an issue –3) Increase allowed granularity to microsecond

6 Arkko, 57th IETF: SEND base protocol issue list 14 - Certificate details Use PKCs instead of ACs for routers and define new options for prefixes? –Pro: Infrastructure for PKCs exists but does not exist for ACs –Contra: New extensions are needed –Certificate chain can not mirror prefix delegation, but not sure how useful this would be Should DNs be used instead of FQDNs to identify trust roots?

7 Arkko, 57th IETF: SEND base protocol issue list 03 - Co-existence scheme & multicast Nodes may run multicast on the link, exchange link- local addresses Since multicast does not use ND, such addresses may traverse from the secure side to the non-secure side Violates addressing RFC Solutions: –1) In the ND-option approach, there are no “sides” and hence no problem –2) Something else, what?