The ND Option Approach for SEND draft-arkko-send-ndopt-00.txt

1. The ND Option Approach for SENDdraft-arkko-send-ndopt-00.txt 57th IETF, Vienna Jari Arkko, Ericsson Research Tuomas Aura, Microsoft Research (In debt for WG draft authors including James, Bill, Pekka, Brian)

2. Presentation Outline • What is it? • What are its benefits? • Are there any problems?

3. Nonce Length Nonce Timestamp Length Time CGA Signature Length Length Key Key hash Signature Parameters The ND Option Approach IPv6 ICMPv6 ND Msg ND Options

4. A Few Technical Details • No modifications to ND (or AH) • Solicited node multicast addresses, unspecified source • No separate address spaces • If nonce verifies, timestamp not used • All CGA processing is in the CGA option • Can be put in its own section or draft • Per RFC 2461 receivers ignore unknown ND options, a CERT- only receiver can accept messages from a CGA+CERT sender

5. Interworking with Classic ND • No separate transition mode! • All SEND-NDOPT messages can be accepted by today’s RFC 2461 implementations • A SEND node, however, makes a decision whether it trusts received ND messages: • A secure entry (e.g. default router) never overwritten by a insecure message • An insecure entry always overwritten by a secure message • In DAD, on first generated tentative address accept also insecure responses. On the next two not. After three attempts, fail.

6. Advantages of the ND Option Approach Process issues: • No modifications to current ND • No need for lengthy discussions about whether its legal to change AH or not • The whole security solution is in one place • Implementation and analysis benefits • Important to

7. Advantages of the ND Option Approach Technical issues: • The security mechanisms have all the relevant information available • Nonces avoid time synchronization issues for solicited adverts • Claimed addresses can be found from their current place in ND • Security scheme of the current message vs. the one that created the entry earlier • Significantly better transition mechanism • Implementation of heavy ASN.1 & cryptographic operations is easier from ND than from AH/CGA header • Only a single set of advertisements needed • Denial-of-Service prevention is easier, e.g. verification decisions can depend on content of the message & internal state

8. Disadvantages? • Can’t think of any technical ones in the SEND scope! • Generalized AH (and maybe CGA) headers could be useful in other applications, too. • Generality is a very desirable goal - but what kind?

9. General Purpose Signaling Protocol Security • What kind of generic mechanism do we need? • MAC/Signature protocol vs. format/library • “OpenSSL of the signaling protocols”? • If your kernel has PK & CGA libraries, they can probably be easily used in another protocol as well -- with the same kind of “all information available” advantages as they have here. • A new extension header may suffice for SEND. But does it suffice for other applications? • One CGA address in SEND, two in MIPv6 RO, three in ...?

10. Summary • All information available • At least as secure as AH • No cross-module APIs needed • No functionality compromises • Useful to think about generic signaling protocol security • But not clear AH++ is the right answer • BAR BoF, anyone?