Subject: Preliminary minutes for SEND WG

From: Pekka Nikander <[email-masked]>
Date: Tue, 15 Jul 2003 16:36:30 +0200

Below minutes edited by me, based on the notes by TJ and Michael.
Thanks to TJ and Michael for their notes.

Please send in your comments ASAP, preferably today, so that I
can submit the minutes to the secretariat.

--Pekka

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.

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------