Minutes from the IETF SEcure Neighbor Discovery (SEND) BOF Details ======= Meeting held 17:00-18:00 at room 303 in Yokohama, Japan at the IETF #54. BOF Chairs: Pekka Nikander, Ericsson (Pekka.Nikander@nomadiclab.com) James Kempf, DoCoMo Communications Laboratories USA (kempf@docomolabs-usa.com) IESG Sponsor: Erik Nordmark, Internet Area Director (erik.nordmark@sun.com) Mailing List: ietf-send@standards.ericsson.net. To subscribe: Send email to Majordomo@standards.ericsson.net with one line in the body: subscribe ietf-send Required reading ================ RFC 2461: http://www.ietf.org/rfc/rfc2461.txt - Basic Neighbor Discovery protocol. http://search.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-02.txt - Threat assessment. http://search.ietf.org/internet-drafts/draft-nikander-send-trust-models-00.txt - Trust models. http://search.ietf.org/internet-drafts/draft-arkko-manual-icmpv6-sas-01.txt - Manual keying for IPsec. http://search.ietf.org/internet-drafts/draft-arkko-icmpv6-ike-effects-01.txt - Interaction between IPsec/IKE and ICMPv6. http://search.ietf.org/internet-drafts/draft-montenegro-send-cga-rr-00.txt - Securing ND using CGA. http://search.ietf.org/internet-drafts/draft-arkko-send-cga-00.txt - Securing ND using CGA. http://search.ietf.org/internet-drafts/draft-kempf-secure-nd-01.txt - Securing ND using id crypto/ABKs. Agenda ====== Meeting minutes =============== o James' presentation about the BOF schedule o James' presentation about the threat model o Pekka's presentation about the trust models: 1. Everyone's trusted 2. The router is trusted 3. No one trusts no one (adhoc) o Jari's presentation about experiences in using IPsec for ND protection - IKE does not support multicast - IKE has a chicken-and-an-egg problem - Large number of manual SAs - Authorization problem for a message type Ran Atkinson: Not true, you assume symmetric crypto. Jari Arkko: Tes, but we are sending the packet to a multicastaddress. James Kempf: Can we take discussion later? - Additional authorization problem to be able to restrict NAs only for the rightful owners of addresses, hard to configure or have PKI support. - Configuration problem: Can't have plug-and-play with traditional security. o Chartering discussion (?) (a period of where no one took notes) - Ran Atkinson: I have running code, a solution from 1995. It uses asymmetric crypto. - Steve Deering: Is this IPsec as in AH and ESP, or also IKE? Please include keying problem as well. - Steve Deering: I think we should include also the case where two hosts in the network operate without a router or when a router goes down. - Steven Bellovin: Note that I'm scheduled to talk about IPsec solutions later. Please postpone ipsec discussion to that time. - Bob Hinden: Let's remember that there are other ways of doing these attacks, e.g. the ietf network attack that happened earlier. If there are easier ways of attacking this solution does not buy that much. - Unidentified: Are you concerned replay attacks from one link to another? Are you concerned about copying a RA from one link to another? - James Kempf: Why don't you post this to the list and we'll deal with it in the requirements work. - Bob Hinden: I have a question of scope, is all of ND included, or also MLD? - James Kempf: I think we have been mainly concerned about ND and RD, not so much other things. We like to keep focused on this problem. - Bob Hinden: Is redirect included? - Pekka Nikander: We have considered it a bit but it's a borderline case whether it should be handled. Definately not beyond redirect. - Erik Nordmark: What assumptions are we making about l2 security? - James Kempf: We need to think about it. - Thomas Narten: Initial focus on ND, look at the threats overall, if we are able to do this, is the end-result useful. - Pekka Nikander: (?) - Ran Atkinson: The observation I'd make: I'm uncomfrotable with the focus. What we want is a km wg that allows bootstrapping, then it would be useful for many other purposes. AH is not a problem, IKE is not a part of the solution set, not now and not even in general. - James Kempf: This is driven mainly by implementation and deployment concerns, wireless background. - Ran Atkinson: IETF is not just about the wireless, its about the global Internet. - James Kempf: We are not limiting ourselves just to wireless, this would be useful for everyone. - Alex Zinin: The problem is important to solve. But we have a specific problem to solve. I'd be okay with going to a web page and downloading a key when coming to a ietf meeting. - Hesham Soliman: ND seems to have an interesting properties of addresses. I wonder if we can go down the path of the general case due to this. - James Kempf: It's easier to have a specific example and then generalize it, rather than the other way around. And take in account deployment considerations! - James Kempf: How many people think it would be useful to work on the problem as stated here? (Many people have their hands up.) - James Kempf: How many people think this is a useless problem? (No hands up.) - James Kempf: How many think we need a general solution? (Almost as many hands are up as in the first question.) - Unidentified: Maybe we should do the first stage, and then decide whether the solution is specific or general - Bob Hinden: (?) - Stewart Cheshire: This is an interesting problem. It would be useful to sit down with a couple of folks and exchange files without ARP spoofing. In the cell phone network its pretty safe, but on a laptop we can accidentally turn on the DHCP server button. - Erik Nordmark: Looking at the charter: learning more about the threats and the bootstrapping problem seems like a useful exercise. Maybe there are uses for the bootstrapping in other cases, but we might be able to do it in parallel. - Erik Nordmark: Who is interested in actually working on the general problem (about half of original people rise their hands) - Steve Deering: Start with a concrete problem, but keep in mind that solution can be more generic. I agree with Hesham. o Brian Zill: Additional threats - What needs securing: NS/NA, RA. RA is tougher and more interesting problem, because you want to show that the router gives you connectivity. Needs to link the router advertisement to some trusted entity, not just authenticate the address. - The topology spoofing goes as follows: attacker can move packets, making a remote node appear on-link. Tunnel en-decapsulation can be done completely transparently to end nodes. Even a secured RS/RA exchange can be moved. Leads to mitm/dos etc. Preventing this requires layer 2 assist. - Ran Atkinson: There's at least a layer 3 and 4 solution. Those are called ESP and TLS. It doesn't matter where the router is, as long as it routes our packets. - Erik Rescorla: this assumes (?) - Steven Bellovin: The last question boils down to authorization. Are you authorized to be a router? o Steven Bellowin: Using IPsec - I'm going to talk about the problem with ipsec. IKE is clearly not the right way to go here. - Reserved IPsec spis were put in the protocol in the beginning for a reason: let's use them. - I'm not proposing a full protocol. I'm suggesting an approach. - Packet format: ESP with special SPI, timestamp, digital signature of SHA1 of , certificate. - What certificate? One answer is an address-based PKI. A *local* pki. Could cryptographically generate IP address from a public key. 63 bits isn't very many, could enemy precompute? - But there are challenges, such as replay protection -- will all nodes have clock? Can certificates be used in conference networks? What about RFC 3041? Use the techniques above for address generation? - Steve Deering: I thought the use of sequence numbers wasn't suitable when cycling through. - Steven Bellovin: I'm suggesting a different type of replay protection. - Steve Deering: Keep in mind that most ipv6 nodes don't do router solicits, they just passively receive a RA. Does that imply that hosts must to do RS always? - Steven Bellovin: This is an engineering tradeoff. - Bill Sommerfeld: (?) - Steve Deering: (?) - Steven Bellovin: You don't have to use IPsec, but it's the packet format that already exists and has the right components. o Gabriel Montenegro: some alternate schemes: CGA, ABK - In CGA, the IID part of the IPv6 addresses is derived from public key using a hash function. Issues with CGA include the limitation to 62 bits (even if salting is possible), IPR. - Securing ND with CGA happens as follows: 1. Sign messages and then 2. Verify signature and CGA property of the address. Securing RD with CGA happens through delegation chains rooted at IANA, heuristics that employ a well-known friend system in the Internet, or other methods. - ABK is based on identity-based crypto, by Shamir in 1984. Requires a Identity-based Private Key Generate (IPKG) which is a trusted third party. o Final comments - James Kempf: That's all we have about this. - Erik Nordmark: I'd appreciate if everyone who is interested in the general problem or the specific problem would join the ietf-send mailing list. (For the mailing list, send e-mail to ietf-send-subscribe@