Subject: Draft SEND WG meeting notes

From: Pekka Nikander <[email-masked]>
Date: Thu, 20 Mar 2003 16:07:48 -0800

Please find attached notes from the Tuesday's WG meeting.
If there is anything to be corrected, please send your
corrections before Tuesday, March 25th.  I will submit
the notes to secretariat after that.

--Pekka Nikander
Securing Neighbor Discovery WG (send)

Tuesday, March 18 at 1545-1645
===============================

CHAIRS:	James Kempf <[email-masked]>
	Pekka Nikander <[email-masked]> 

AGENDA:

5 min. - Agenda discussion, chairs

The agenda was accepted.  The chairs later on changed it so that
the second last item, interaction with PANA / DHCP, was moved after
the last item, draft status and schedule.

10 min. - Last Call Issues as resolved for draft-ietf-send-psreq.txt,
          Pekka Nikander

Pekka Nikander went over the issues raised during the WG last call.
Most of the issues were minor.  However, there were two larges
issues, worth spending some face-to-face time.

The fist issue centered around using the term "trust".  Currently the
draft uses the term trusts, trusted, trustworthy etc in multiple
place.  However, it would be better to replace the word with more
specific words, e.g. "delegation", "authorized", etc.  Pekka
described how the word is used right now, but also told that he is
not very happy with the current resolution of the issue.  Bill
Sommerfeld came up and promised to come up with alternate wording
suggestion by the end of next week (March 28th).  It was decided that
if Bill comes up with an acceptable alternate wording, that will be
incorporated to the next version of the draft.  Otherwise the current
wording will be used.

The other problematic issue was that the current draft discusses a
nummber of possible solutions.  Even though these solutions are only
used for illustrative purposes, some people had been raised the
question on the mailing list whether a problem statement document
should include this kind of text at all.  The discussion at the
mailing list has inconclusive.

James Kempf (taking his chair hat off) supposed that the solutions
text should be left in the draft, after all, as examples.  Bill
Sommerfeld supported that, and Alper Yegin (who had raised the issue
originally) agreed that the solutions can stay in as long as it is
explained that they are just examples.  Thus, the decision was to
keep the solutions in the text.

10 min. - Self Signed Certificates for CGAs, Tuomas Aura (presented
           by Pekka Nikander)

Pekka Nikander presented Tuomas Aura's slides on his generic draft on
using Cryptographically generated IPv6 addresses (CGA).  (See the
slides).  

Pekka told that as far as he knows, the idea is covered by IPR at
least by Ericsson and possibly Microsoft.  Ericsson has recently
released the IPR on this; the statement has been posted to the mailing
list and is available at the IETF IPR page.  The chairs are discussing
the issue with Microsoft now.

Hesham Soliman asked whether is the IPR on the CGA idea, or on
specific applications?  Pekka replied that as far as he knows, the
IPRs cover the CGA idea itself.

One of the biggest technical problems with CGA so far has been the
fact that the IPv6 address structure limits the hash length into 62
bits, which is somewhat insecure.  The basic idea in
draft-aura-cga-00.txt a method for removing this 64 bit limit by
introducing a security parameter (sec) and a seconnd hash (see the
slides).  With this technique, the cost of address generation and the
cost of attacks are increased, keeping their ratio 2^59, but the cost
of verification remains constant.  Furthermore, the additional cost
possibly imposed at address generation can be divided over multiple
addresses, since the second hash is independent on the routing prefix
and can therefore be used multiple times.

In addition to solving the problem with short hash lengths the draft
provides exacts algorithms and formats for using CGA addresses.

After the presentation Jari Arkko went to the microphone and expressed
that he liked this draft, and that it looks good for fast mobility.

20 min. - Open Issues on draft-ietf-send-ipsec-00.txt, Jari Arkko

(see slides)

The Design Team has now worked on a solution for some time now, and
the draft represents a snapshot of the current thinking.  Jari first
went through the overall design, and the continued to the most
important issues with the document.

The first issue with the document is that it has somewhat broad
scope, describing several more or less indipendent techniques, and it
looks like the final draft might become quite large.  Furthermore,
since CGA is covered by IPRs, it may be necessary to split the CGA
dependent portions of the draft out.  

James Kempf opinioned that if the Working Group is able to get the CGA
IPR released, the draft does not have to be split.  A split could slow
down the process.  Thus, all parts should go together.  Bill
Sommerfeld seconded that splitting out CGA makes sense.  Alper Yegin
said that since there are two independent problems and solutions,
Neighbor Discovery and Router Discovery, it makes sense to split, so
that one or the other part can be replaced with alternative methods
when they are available.

After some discussion the chairs declared consensus on that if CGA IPR
not resolved, we need to split CGA as a separate part.  Otherwise,
we'll go with one draft, since there doesn't seem to be any
compelling reason to split, and there seems to be different
suggestions for splitting, without any single one getting any larger
support. 

The second open issue considered the presented transition scheme.  The
basic idea in the transition scheme is to view the link as two
separate logical links, one being secured with SEND and the other one
not.  Alper Yegin noted that there is a problem with DAD when some
nodes do not support SEND.  That can lead to colliding link-local IPv6
addresses.  Erik Nordmark noted that the two colliding addresses
should be considered to be on two separate links, so no problem.
However, this might require implementation considerations.  Pekka
Savola noted that possibley one could also look at the G bit.  Erik
Nordmark continued that what doesn't work in this case is that DAD is
not going to detect two identical mac addresses being same.  This
has some disadvantages.

In general, it looks like the transition scheme has still some open
issues and requires more consideration.

The next open issues considered solicitations.  Some soliciations have
side effects, and therefore they should be secured.  However, some
solicitations use unassigned source address, and therefore it is very
hard to secure them with CGA.  Dave Thaler said that there is clearly
a threat with the solicitations, the solution should handle
it.   Additionally, the requirements draft should talk about this
threat.  It was agreed that the requirements draft must be updated to
handle this.

5 min.  - Draft Status and Schedule, chairs

James Kempf discussed the draft status and schedule (see slides).
There was no discussion.

10 min. - Interaction with PANA / DHCP, chairs

The final item considered interaction with SEND and PANA and DHCP.
Pekka Nikander described some possible scenarios, mainly made to give
people something to think about.  (see slides)

Bernard Aboba said that passing PANA created keys between various
parties is not a good idea.  The overall system looks very complex,
and analysing it would be a nightmare.  Parijat Mishra said that in
his opinion this is a good idea.  If we don't do this, we'll end up
with too many keys.  Bill Sommerfelds reaction was similar to that of
Bernard.  There is gotta be a better way.  Erik Nordmark said that a
short write up on what kind of problems we are solving here would be
useful.