SEND Working Group Minutes
==========================

IETF57, Vienna, Austria
Monday, July 14, 9:00 am

Minutes produces by the chairs, based on notes taken by TJ Kniveton and 
Michael Richardson.  Thanks to the notetakers.

Executive summary
-----------------

draft-ietf-send-psreq-01.txt is at the IESG, waiting for review.

The working group deciced to move from using IPsec into using ND 
options.  Discussion on some smaller open issues needs to continue at the 
mailing list. The document editor will revise the document soon, and the 
plan is to have the next version of protocol draft will be out at the end of 
August, possibly with some certificates related work to be done.  WG last 
call is expected in October.

Moving from IPsec to ND options requires re-chartering.  This is OK with the 
ADs.

The IPR holders on CGA have released they IPRs (royalty-free license) on CGA 
for SEND purposes; CGA is technically almost completed.  WG last call is 
planned in August.

Introduction and Agenda Bashing (5 min.) Chairs

-----------------------------------------------

  Introduction and Agenda Bashing (5 min.) Chairs
  Draft Status (10 min.) Chairs
  Implementation Report (20 min.) Pekka, James
  IPR discussion (10 min) all, with chairs moderating
  Open issues in draft-ietf-send-ipsec (20 min) Jari
  IPsec, IPsec w. CGA Header, or ND options?
     ND options (10 min) Jari
     IPsec w. CGA header (10 min) Pekka
     technical discussion (40 min or until done),
     all with James moderating
   Summary and Way Forward (10 min). Chairs

Draft Status (10 min.) Chairs
-----------------------------

draft-ietf-send-psreq-03.txt has been submitted to the IESG at the end of 
April, intended to be published as an Information RFC.  The IESG review has 
not begun yet.

draft-ietf-send-ipsec-01.txt has a number of open issues, the largest of 
which was to issue of whether to use IPsec or ND options.  The issue was 
resolved, and ND options will be used, as reported below.

draft-ietf-send-cga-00.txt is fairly close to be completed, but some 
details still need discussion at the mailing list.

Implementation Report (20 min.) Pekka, James

--------------------------------------------

Pekka went over implementation notes for FreeBSD.  Basically, they did not 
get very far before realizing that the WG draft needs some changes.  
Firstly, directly mixing CGA and AH is a bad idea.  There would be a need to 
change PF_KEY data structure quite a lot. Secondly, doing PK crypto is hard 
without kernel threads, so PK crypto operations need to be passed to user 
space (possibly through the revised PF_KEY interface).

What comes to the CGA draft, it seems fairly good.  It was easy enough to 
implement an ifconfig extension for CGA configuration.  However, 
generating the modifier must be done with a separate user space tool, 
since it may take a long time to compute.

PF_KEY and ifconfig can be used for communication between the user space and 
the kernel space.  Bigger issue is whether to do PK operations in a 
kernel thread or at the user space.

The code is available by request.

James described another implementation, written by Jonathan Wood.  It 
partially implements the WG draft on linux 2.5.x (w/ IPsec for v4 and v6).  
The focus of the implementation work was replicating what a vendor would 
implement, and to be conformant with the IPsec RFCs.

One of the results is that the WG draft approach would have a major 
impact on the IPsec fast-path (interrupt context at bottom of driver). RSA, 
ASN.1, and cert chain retrieval are not realy suitable for the 
interrupt context.  Additionally, the approach would have a high impact on 
the IPsec transform interface, the existing one in the Linux kernel 
wouldn't work.  Hence, no work would saved by using IPsec because 
implementation has to be restructured.

What comes to CGA, it seems to be ok for kernel use as specified. 
However, it is best to be implemented with a specialed ASN.1 parser, which 
leads to losses in extensibility.

Performance results are shown on the slides.

Summary: The Linux IPsec design is not well suited for PK 
algorithms; SEND implementation would require restructuring of kernel fast 
paths.  CGA gets good, efficient results (based on Sec parameter).

Michael Richardson: Linux 2.5 implementation of IPsec does not support 
async hardware offload of cryptographic operations.  Going to external hw 
for symmetric crypto, you have to suspend all processing; 
effectively same problem as doing RSA in user space.  May need to 
re-evaluate the conclusion that there is no advantage of using IPsec, 
because the Linux hardware acceleration code is < 6-8 months old.  The code 
is not in 2.6; don't know when API will get to usable hw offload.

Pekka: Someone might want to implement on OpenBSD which already has hw 
offload.  Regarding second point, with AH just as a PK algorithm 
(without CGA), there is no need to restructure the kernel transport 
interface.

Bob Hinden: What about people building low-power, slower systems.

James: If Sec is 0, it is only microseconds.

Bob Hinden: If we want this to be useful everywhere, CPU performance is an 
issue.

Pekka: Hash extension pre-computation has to be done once.  So for sec 
higher than 0, you can offload pre-computation to another node. Don't need to 
do it again unless you change your public key.

IPR discussion (10 min) all, with chairs moderating

---------------------------------------------------

Ericsson released IPR before SF IETF.  Microsoft has released IPRs about a 
week ago.  These are royalty-free, non-discriminatory licenses.  
However, do read IPR notes at IETF site for details.

As far as the chairs know, there are no other IPR claims.  Anyone 
knowing about IPRs related to draft must inform the IETF.

Based on this, the chairs polled on objections on using CGA? (no).The WG 
decided to go ahead and use CGA.

Open issues in draft-ietf-send-ipsec (20 min) Jari

--------------------------------------------------

Very good reviews received during the last month.  The resulting issues all 
at the URL shown on slides.

Issue #7 - certificate-only ND protection
- - - - - - - - - - - - - - - - - - - - -

Complaint: not well thought out.  The authors agree.  The authors 
proposal, based on new information about IPRs, to remove the text of using 
certificates for ND; just rely on CGA.  ND certificates could be added as an 
extension later.

Francis Dupont: Don't believe dropping ND certificates is a good idea. CGA 
does not provide the same properties.

Jari: With certificates, can also ensure this node is a member of this 
company, etc.  Agreed.

Michael Richardson: Don't think I understand your proposal. Is it to say I 
will use a CGA address signed by key, but PK is not authorized by CA. 
(yes.) I rather we went forward quickly, but I am concerned that req for 
retrieving cert chains may be significant chain to state machines and 
operational pieces. Might find ourselves in a bad situation in the future 
because it may be hard to add later.

Jari: Yes, but for discovering routers, we would still use 
certificate discovery. Just drop it for NS & NAs for now.

Rick A.?: Isn't is straight-forward to add a capability in hosts to say no, I 
don't have a certificate chain. Because you should provide trust chain, but 
you can give a simple NAK. I don't have a trust chain to give you. At 
least you know that you got a response.

Jari: Current spec has some aspects of that.  But some details have not 
been fully thought out. It's a little tricky with addressing, before ND is 
complete.

Pekka: More practical problem is that we'd like to advance draft, and 
current text is not specific enough.  We'd like to leave it out for now.  If 
anyone in room would like to rewrite?  Otherwise we would like to take out.

Rick: I'm willing to work on text, either for WG draft or parallel draft.

James: Issues with certificate interoperability as well.

Pekka Savola: We have to consider scenario where this would give 
additional protection.  Where layer 2 or lower has not 
authentication to network. So what is the applicability?

Pasi Eronen: Agree with chairs that it should be dropped now.  Current spec 
does not say how it should work.  So there is no section in draft to 
remove.

James: Some L2 protocols provide certified MAC address.  That would be 
ideal situation for SEND. But Cable Licensing? is only L2 protocol that 
does that.

The WG decision was to remove the ND certificate facility for now. 
However, if someone (Rick?) produces a separate draft on that, it can be 
accepted as a WG item.

Issue #14: CGA RD protection useful?
- - - - - - - - - - - - - - - - - -

Michael: To me, this seems like worst of both worlds. We have code for 
both; can't use both; we have to deal with certs in kernel even when we 
don't want to talk to peers. Don't see optimizations except towards 
shortest IETF process.

Jari: Different problems: ND problem, RD problem. Need slightly 
different security solution

Pekka: Might help on router discovery for ad-hoc networks.  But this is not 
the focus of WG.  So dropping this is OK with me.

Tuomas: Might make sense to protect, even if you don't have 
authorization for the router, to prove address ownership.

Michael: Any network that doesn't have certificate is an "ad-hoc" 
network, e.g., this network at Telekom Austria, since DNS was not 
reloaded on Monday morning.  Can't get certificate because they're 
closed.  Maybe we should have more documents: How to protect ND with PK, how 
to protect RD with PK, how to get PK addressed CGA, how to deal with cert 
retrieval.  We could proceed with getting reviews of some of the pieces.  I 
feel afraid of getting a certificate for my router, because 95% of people 
won't be able to do that without putting out dollars.

James: This is mainly simplicity. CGA with RD doesn't provide a lot of 
security, just that router is authorized to send packet with the 
address.

Dave: Question is whether threats are significant enough to protect 
against

Pasi: CGA-only RD protection may not be useful, but used with 
certificates, it might be.

Rick: Isn't really secure to use CGA on these things, but you can choose any 
prefix you like, so it may be possible hijack a prefix.

Dave: True, but this is denial of reachability.

Rick: Unless you can tunnel to a different link.

Tuomas: Using CGA and certs together makes sense, because you may trust 
router for a prefix, but not to steal IP address of another router on the 
link.

Pekka: Getting feeling we want to use CGA with certs, but what about CGA 
without certs?  We can discuss on the ML.

Issue #6 - Millisecond granularity for protecting against replays is not 
fine enough?
- - - - - - - - - -

May be future high-speed link where this is problematic. Can decide this is 
not an issue (1000 messages/s is enough), or change rule that you can 
still receive during same 1-ms interval, but monotonically 
increasing.  Normally we try to prevent replays, but for ND & RD, replay 
"attacks" in short amount of time may not be a problem.

Pekka: slight difference in semantics of timestamp between ND options and 
CGA header.  In the CGA header approach, the timestamp is a kind of 
lifetime for the security association, but in ND options, it's just a 
timestamp.

Michael: I would prefer you put 16 bits of decimal-point seconds. So 
seconds / 64k (50 us).  Monotonically increasing seems simpler. Do you 
really need to produce thousands or millions of ND messages per second?  May 
be a question to mobile phone operators, for rate of movement from one BS to 
another. Or how fast are trains moving in the future.

Jari: Large # of nodes on the same link may cause this. But currently 
limits on how fast routers respond to router discovery. But I like your 
suggestion about 64k.

Dave: What is resolution?

James: Jari will make a suggestion to the list.

Issue 14 - Certificate details (James)
- - - - - - - - - - - - - - - - - - - -

Comments from review board - problems using attribute 
certificates. RFC3281 is a fairly New spec, not a lot of 
infrastructure in place as with PKC certs.  A disadvantage of using PKC 
certs is that we need a new extension.  We would have certificate chain 
mirroring prefix delegation.

Unfortunately, attribute certificate chains not permitted by RFC 3281.  
However, there seems to be some interest for doing this in BGP or SBGP.

Distinguished Names to identify trusted roots.

Michael: New code is needed, period.  Every single thing requires new code in 
their CAs.  ASN.1 is not that extensible in the real life, as you know if 
you have written any code. "There is no infrastructure" is a red 
herring.  Reality is that someone is going to write code.  Let's write code 
that the X.509 people have suggested, authorization certs.

DNs are not useful. Let's use FQDNs, because we should tell them what to do.

Pekka: No opinion about DN vs FQDN, but regarding certs, strongly agree 
with Michael that we should go with authorization certificates. Use 
object hash as an issuer (i.e. PK instead of name).  Simple change, 
already there in RFC3281 ASN.1 specification, just need to remove 2 lines 
from the RFC (the statement that using an object hash as an issuer 
explicitly forbidden).

Russ Housley: I put those lines there; so far I haven't heard a 
reasonable justification for removing them.  I agree with attribute 
certs, but not convinced that constructing hierarchy is the answer. What 
structure are you trying to create?  What are you trying to find tha 
attribute certificate to?  PK and things you're binding to PK have 
different lifetimes.  So, extension to PKC certs is not good; use 
attribute certificates.

Pekka: Scheme we would like to support is chain of ISPs, with 
higher-level and lower level ISPs, or even users running their own 
routers.  Chain of attribute certificates based on prefix, 
sub-prefixes can be delegated down the chain.  Name of ISPs doesn't 
matter to the party doing the verification, just that there's a secure 
chain of PKs, and that the prefixes properly nest so that the router is 
authorized to advertise the prefix.

Russ: We'll have to talk later.

James: Let's take it to the list and talk about it more. I'll generate 
proposal for options with Jari.  No one wants to use PKCs.  Anyone 
support getting rid of attribute certs and going to PKCs? (no).  We'll talk 
about attribute certificates later.

IPsec, IPsec w. CGA Header, or ND options?

------------------------------------------

Mostly an architectural issue - should we use IPsec, PK crypto at all for 
this type of thing?

ND options (10 min) Jari
- - - - - - - - - - - - -
(see slides)

Erik Nordmark: Last benefit on slide - can you actually reverse 
processing, and source is already in your path.  Packet is not going to 
change my state, so I will skip checking security part?

Jari: Don't have details on that, but there are potential DoS dangers. PK 
operations, without knowing whether IP address on other side exists.  If 
everything is on one layer, we can make that sort of scheme as you 
suggested.

James: This is to use ND options, and generic signalling protocol may come 
out of this, but it would be handled by another WG.

CGA header approach for SEND - Pekka
- - - - - - - - - - - - - - - - - - -
(see slides)

Discussion starting
- - - - - - - - - -

Michael: I prefer AH philosophically.  Comes down to scope of effort. Is 
this security neighbor discovery, or public-key motivated AH working 
group?  Issues with IPsec wg are irrelevant.  Whether 2461 says to use AH is 
irrelevant. 

IPsec didn't reject SKIP because it was in-line, but because it wasn't a 
real key management protocol that scaled beyond an enterprise. Tried to 
figure out how to use PK inline, but at the time it didn't work. I would 
like to see it happen. If this WG goes with ND (i'm sitting on the 
fence), I believe IPsec should retire AH. IPv6 should remove it from their 
documents. It clearly is a failure.  IESG should understand that AH is 
unimportant. 

I will refrain from offering an opinion on which one I like. 

Pasi: I have a feeling that there's a difference in 
functionality. ND option allows nodes that have clocks, no clocks, or bad 
clocks. IPsec/AH requires synchronized clocks, or nobody checks 
timestamps.  Other differences are which is easier to implement.  
Certainly ND options, so I prefer that. 

Pekka: I disagree about timestamps. Sender is providing timestamp, so 
sender may say that I don't have a clock. Sender is the one at risk, so it 
can choose whether to put timestamp. 

Erik: Comment about generality.  Using MLD for anycast.  CGA-based 
anycast addresses could allow you to apply same technique.  IP address 
you're protecting is not source address, but one in payload.  CGA+AH would 
look at wrong address.  There might be slight differences in 
generality. 

Steve Bellovin:  I sent out first message calling AH useless in 1995.  It 
was largely kept alive for things in IPv6.  I'm not going to tell IPsec wg to 
get rid of it; there's enough sentiment. 

(aside from Bob H. - we thought you said we had to use it) 

Steve Bellovin: lesson learned of 2461 - unless you do hard work of 
making sure it works, you can't be sure it will apply. 

Packet signing -- unless you do work of figuring out how to do it, it may 
not work.  Using generality of AH here might not get you generality 
anywhere else.  Don't use that as a consideration. 

Bob Hinden: Idon't have a strong opinion on two approaches.  Sounds like 
putting it in ND has an easier transition.  You're going to have to have a 
mixed environment for this to get useage.

James: Follow up discussion on timestamp? (no)

Consensus call (see slides):

Question 1:
(A) no one raised hand.
(B) 20 raised hands.

Question 2:
(A) no raised hands.
(B) 34 raised hands.

Will move forward with draft-arkko-send-ndopt-00.

Erik: What has been learned by looking at applying IPsec here would be good 
to get that written down. 

James: Pekka and Jari have a paper relating to this, perhaps they could 
submit it to IPsec wg. 

After IETF, we'll do a last call on the CGA draft, also submit to SAAG.  
Will continue with ND options, send to review group and IPv6 group.  Not 
clear if we'll meet at next IETF; depends on whether issues come up.  
Currently on-track for original goal to finish within a year.