Subject: ND-options based approach instead of AH

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Jun 2003 14:53:13 +0300

Hello,

Given that we seem to be opening an architecture discussion about
the protocol pieces, I'd like to propose an scheme based solely
on Neighbor Discovery options. Functionally, this scheme is almost
equivalent to the current mechanism in the WG draft, or the CGA
extension header separation proposed by Pekka. However, this
scheme offers the following benefits:

* The full security solution is in one place, easy to
   implement and analyze.
* The CGA parts are easily separable into a different
   draft, if the IPR considerations require this.
* The security solution can directly use ND layer
   information, such as Target Address.
* Transition scheme appears to be smoother, and
   requires only one copy of each message broadcast on the
   link whereas the current approach required two.
* No Neighbor Discovery modifications are required, only
   extensions.
* No IPsec extensions or modifications are required.
* No extension header numbers are used.

A more in-depth list of the differences can be found from
   http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndopt.html#comptoipsec

I have taken the liberty of producing a drafty draft
for this approach. The draft is available at:

   http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndopt.txt
   http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndopt.html
   http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ndoptdiff.html

The draft is intended only for the purposes of discussing
alternative solutions. It derives the material largely from
the current WG document.

It also has open questions. One bigger item is the
security differences of the current transition approach
vs. the approach I'm suggesting here.

Disclaimer: I'm reasonably happy with the current WG
draft as well and it works. But given that we started a
discussion based on implementation experiences and
correlating data in different pieces of the stack,
perhaps this approach is something that we should
look at.

--Jari

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