Subject: Re: I-D ACTION:draft-savola-v6ops-6to4-security-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 May 2003 10:25:39 +0200

I'm wondering what we should do with this draft.

It seems to me to be basically correct (i.e. it says that
there are specific spoofing and DoS attacks using 6to4 that
are harder to trace than "standard" spoofing and DoS attacks).

It is more explicit about the checks to be applied than the base
6to4 specification, but those checks cannot eliminate the attacks.

The document might also assist intrusion-detection implementors
in detecting these attacks.

So I think it should probably be published as an Info RFC, and
if/when we revise the basic 6to4 spec, Pekka's document would
be a source for improving the security section.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 5 May 2003 09:00:10 +0300 (EEST)

I'm a bit biased to answer this, but..

> I'm wondering what we should do with this draft.

I've been wondering about the same too, due to lack of feedback since the 
last revision from the WG.  I must assume it's perfect ;-)
 
> 6to4 specification, but those checks cannot eliminate the attacks.

True enough, they should make it easier to implement 6to4 properly.  This
is also possibly something that could form a basis on what to ask from the
security side if we progress 6to4 to Draft Standard one day.
 
> be a source for improving the security section.

Pretty much agree, informational seems to be the best way here.  

If we need to fork off separate efforts to modify 6to4 spec or augment
that, it should be in separate, short documents referencing this.

In short, it seems to me that we can't find a proper solution that would 
satisfy everyone at the moment (and we may not even need one really 
badly), so it might make more sense to just push the documentation of the 
issues out and leave specific solutions for later.

Easier to get consensus on this than a specific solution, I think.

-- 
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: Margaret Wasserman <[email-masked]>
Date: Mon, 05 May 2003 15:27:25 -0400

Hi Pekka,

Do you think that this document is ready for WG last call for
informational, then?

Margaret

---

From: Pekka Savola <[email-masked]>
Date: Mon, 5 May 2003 23:10:13 +0300 (EEST)

> Do you think that this document is ready for WG last call for

I think it's pretty much ready. (There are two TBD's, but those can be 
filled in/removed later, and are not crucial; I also need to make a few 
minor ID-nits -type corrections, but those can be done later.)

...

As for the other perspective into this..

One potential problem may be that it isn't formally a WG document (at
least yet).  The question was asked in a session a couple of IETF's back,
but there was pushback then (IIRC -- I think it was because there was
belief that we couldn't really secure 6to4 -- and the focus has now been
on documenting the issues rather than making it bulletproof), but then
again, the document has also evolved since then.

Looking at RFC2418, there seems to be no strict guideline for something
like this.  It seems that any document the WG is working on and touches
its area of expertise could be last-called and even sent to the IESG -- no
need to have it formally approved.  But the practice seems to be
different.  So, the options would seem like:

 1) get WG feedback whether it could be accepted as a WG document,

 2) announce a WG last-call, and/or

 3) send it to the IESG (after possible modifications).

in any possible order (e.g. I could send it to the IESG as an individual
submission, and in turn, it would likely be pushed here for Expert review,
for which a last-call -like process would be necessary) -- but 1-2-3 or
1+2 concurrently and then 3 would seem the most natural approach to me.

Seems a bit confusing, but maybe something like 1+2 would seem 
appropriate.

Getting some action kickstarted before the next IETF, at least, would be
excellent and might reduce the WG load then.