Subject: HTML version of draft-ietf-send-psreq-01 available

From: Pekka Nikander <[email-masked]>
Date: Thu, 23 Jan 2003 15:18:25 +0200

Folks,

A minute ago I submitted a revised version of draft-ietf-send-psreq
to the repositiories.  Text, HTML and XML versions of the draft
are available at the interim web page:

http://www.tml.hut.fi/~pnr/SEND/

The HTML version is directly available at:

http://www.tml.hut.fi/~pnr/SEND/draft-ietf-send-psreq-01.html

Our intention is to get last call going later this week or
early next week.

--Pekka Nikander

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 23 Jan 2003 09:32:40 -0800

WG Last Call on draft-ietf-send-psreq-01.txt starts today and runs for two
weeks, until Feb. 6. This draft is intended to be a comprehensive security
analysis of threats to Neighbor Discovery as it currently exists today in RFCs
2641 and 2642, according to three different trust models that group current
network deployments into three different equivalence classes. As such, it
functions as a requirements template for the SEND design team.

It is *extremely important* that this draft be read and commented on by the WG
prior to submission to the IESG. Please make an effort to review the draft
within the Last Call period, and submit any comments to the mailing list or the
editor (Pekka).

 Text, HTML and XML versions of the draft
are available at the interim web page:

The draft was submitted to the IETF drafts respository today and should show up
there shortly.

            jak

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 31 Jan 2003 12:56:36 +0200

James Kempf wrote:
> weeks, until Feb. 6. ...
> prior to submission to the IESG. ..

So far there haven't been any comments.  Maybe the draft is prefect :-)

Anyway, I hereby solicit *both* comments and just notifications
that you have read the draft and think that it is great.  James
and I just want to have feedback.

Thus: If you read the draft, or have already done so, please
drop me (or at the list) mail, even if you have no comments.

--Pekka Nikander

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Jan 2003 15:08:11 +0200 (EET)

> drop me (or at the list) mail, even if you have no comments.

I've read it and it seems fine, except for a few nits (most of them 
ID-nits material).

Nits:
 - in the w.g. name s/Secure Neighborhood Discovery/Secure Neighbor 
Discovery/
 - in the title s/IPv6 ND trust & threats/IPv6 ND trust models & threats/
 - RFC2461/RFC2662 -> RFC2461/RFC2462 
 - s/redirect attack if the tacker/redirect attack if the attacker/
 - the threat table is way too wide (by 12 chars), suggest cutting down on 
attack names and shifting to left; the AD/rfc-editor would kill for this ;-)   
 - references need to be split to informative/normative

Also, there are a few non-showstopper items that I have been waiting input
on;  from Jari mostly;

1)

message: Mon, 02 Dec 2002 10:16:22 +0200, consisting of e.g.:

--8<--
> IMO, section 7 of [MAN-SA] is not specific to manual ICMP SA's and should
> be removed to either separate draft or here.  There might be more, other
> generic security discussion there.
> 
> Perhaps Jari might have an opinion?

Jari is on vacation this week but I'm sure he'll return to
to this issue.
--8<--

- Did Jari's comments on Sun, 17 Nov 2002 17:31:14 +0200 make it to the 
draft, I didn't see any follow-up discussion?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "James Kempf" <[email-masked]>
Date: Fri, 31 Jan 2003 08:30:19 -0800

>  - references need to be split to informative/normative

I don't believe this is necessary in a non-standards track RFC. Requirements are
typically published as informational.

            jak

---

From: Pekka Savola <[email-masked]>
Date: Fri, 31 Jan 2003 18:39:36 +0200 (EET)

> typically published as informational.

It is necessary or at least _strongly_ encouraged, and apparently a source
of a lot of confusion.

Here's one perspective at the issue:
--8<--
Date: Thu, 02 Jan 2003 07:58:34 -0500
From: Thomas Narten <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-v6ops-3gpp-cases-01.txt 

> yep, I only did editorial nits, and tried to make it conformant with
> the ID nits. However, I did not split the references to normative
> and informative. The document is going to be Informational, and so I
> would guess that all references are informative by definition. (This
> would be my understanding.)

Whether a reference is normative or not has little to do with whether
a document is on standards track or not. It has to do with how
critical the reference is to understanding and/or implementing the
document at issue. I.e, if a document says, one SHOULD/MUST do foo, as
defined in RFC XXX, that is a normative reference, as one can't really
implement foo without having the referenced document at hand. It does
not matter whether the documents are or are not on the standards
track. 

Thus, it is useful to split references into info/normative in almost
all cases. This helps the *reader* better understand  whether the
reference is just informational or more important.

See draft-rfc-editor-rfc2223bis-03.txt.

Thomas
--8<--

---

From: "James Kempf" <[email-masked]>
Date: Fri, 31 Jan 2003 09:20:00 -0800

OK, I stand corrected.

            jak

----- Original Message -----
From: "Pekka Savola" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Pekka Nikander" <[email-masked]>; "SEND WG"
<[email-masked]>
Sent: Friday, January 31, 2003 8:39 AM
Subject: Re: WG Last call on draft-ietf-send-psreq-01

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 31 Jan 2003 19:38:01 -0800

Pekka,

it is a well written document. thanks.

but one thing irked me. it is a document about 'Trust Models and 
Threats'. why there is a need to talk about solutions?

>    Since there are no a priori trust relationships, the nodes cannot
>    rely on traditional authentication.  However, it is still possible to
>    use self-identifying mechanisms, such as Cryptographically Generated
>    Addresses (CGA) [9].  These allow the nodes to ensure that they are
>    talking to the same nodes (as before) at all times, and that each of
>    the nodes indeed have generated their IP address themselves and not
>    "stolen" someone else's address.

>    In the ad hoc network case, and optionally in
>    the other two cases, the nodes may use self certifying techniques
>    (e.g.  CGA) to authorize address bindings.

do we know how to use CGA for ad hoc networks? is it written
down somewhere. [9] is about protecting MIPv6 signaling. maybe
somebody has already figured out how to use it for ad hoc 
networks. but it is not obvious to me.

I would like to avoid talking about solutions now.

Vijay