1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document...

7
1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document draft-ietf-send-ipsec-01.txt http://www.piuha.net/~jarkko/publications/send/ issues 57th IETF, Vienna Jari Arkko, Ericsson Research NomadicLab

Transcript of 1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document...

Page 1: 1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document draft-ietf-send-ipsec-01.txt jarkko/publications/send/issues.

1Arkko, 57th IETF: SEND base protocol issue list

Issues in the SEND base documentdraft-ietf-send-ipsec-01.txt

http://www.piuha.net/~jarkko/publications/send/issues

57th IETF, Vienna

Jari Arkko, Ericsson Research NomadicLab

Page 2: 1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document draft-ietf-send-ipsec-01.txt jarkko/publications/send/issues.

2Arkko, 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?

Page 3: 1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document draft-ietf-send-ipsec-01.txt jarkko/publications/send/issues.

3Arkko, 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

Page 4: 1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document draft-ietf-send-ipsec-01.txt jarkko/publications/send/issues.

4Arkko, 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

Page 5: 1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document draft-ietf-send-ipsec-01.txt jarkko/publications/send/issues.

5Arkko, 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

Page 6: 1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document draft-ietf-send-ipsec-01.txt jarkko/publications/send/issues.

6Arkko, 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?

Page 7: 1 Arkko, 57th IETF: SEND base protocol issue list Issues in the SEND base document draft-ietf-send-ipsec-01.txt jarkko/publications/send/issues.

7Arkko, 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?