Current Meeting Report

2.3.12 SEcuring Neighbor Discovery(send) Bof

Current Meeting Report

Minutes from the IETF SEcure Neighbor Discovery (SEND) BOF


Meeting held 17:00-18:00 at room 303 in Yokohama, Japan at the IETF

BOF Chairs:
Pekka Nikander, Ericsson (
James Kempf, DoCoMo Communications Laboratories USA (

IESG Sponsor:
Erik Nordmark, Internet Area Director (

Mailing List: To subscribe: Send
email to with one line in the body:

subscribe ietf-send

Required reading

RFC 2461: - Basic Neighbor Discovery
- Threat assessment. -
Trust models. -
Manual keying for IPsec. -
Interaction between IPsec/IKE and ICMPv6. -
Securing ND using CGA. - Securing ND
using CGA. - Securing
ND using id crypto/ABKs.


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

- 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

- 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

- 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

- 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
<ND, timestamp>, 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

- 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@


Experiences in Securing ND with IPsec
CGA and ABK for SeND
What needs securing?
Trust Models
(Ab?)Using IPsec for SEND