Subject: WG Last Call: draft-ietf-v6ops-6to4-security-02.txt

From: Pekka Savola <[email-masked]>
Date: Wed, 2 Jun 2004 13:40:49 +0300 (EEST)

Hi all,

(co-chair hat on)

This is the WG Last Call for comments on sending
draft-ietf-v6ops-6to4-security-02.txt, "Security Considerations for
6to4" to the IESG for consideration as Informational:

http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6to4-security-02.txt

Please review the document carefully, and send your feedback to the
list.  Please also indicate whether or not you believe that this
document is ready to go to the IESG.

The last call will end in 2 weeks, on 16th June.

Thanks!

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Jun 2004 16:41:51 +0200

I think this is ready to ship.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 2 Jun 2004 17:08:00 +0100

Ready to ship, I agree, and a nice piece of work!

Minor nits:
- Missing opening bracket on text spanning page 8 bottom split.
- Delete 'the' in 'the Section' at start of 4.1.3
- Bottom of 4.3, remove the XXX line
- send-ndopt and psreq I-Ds now at draft 5, April 2004
- ISATAP is now at Draft 22

Minor comment:
- Should p.15 recommend against using the anycast source address?

Do we have field reports of 6to4 abuse to date?  (Curious if they are
recorded anywhere)

It seems many ISPs (NRENs, usually) simply avoid advertising 2002::/16
outside their border, or the IPv4 anycast address outsude their border,
to limit their "traffic magnet".   I guess this is your model in 
Section 6.2, but you talk about 2002::/16 limitation, rather than the
IPv4 anycast limitation?   This is probably why most people see SWITCH's 
relay ;)   While there are enough "third party relays" (as you call them), 
the closed model still appears to work because of the current traffic
levels and available relays like SWITCH's.

It's not clear how many recommendations in your (very thorough!) draft 
are widely implemented - would be very interesting to know...

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 3 Jun 2004 08:56:06 +0100

Another comment:

The example in 6.1 cites compatible addresses.   While these are in use,
they are being deprecated in draft-ietf-v6ops-mech-v2-02, so I suggest
the example is reworked a little and that the reference is to the new
draft and not RFC2893 (reference [4]).

Tim

---

From: Fred Templin <[email-masked]>
Date: Thu, 03 Jun 2004 09:33:12 -0700

>draft and not RFC2893 (reference [4]).

I agree with Tim about updating the [MECH] reference, but I was also
wondering about when it would be OK for implementations to begin
dropping support for IPv4-compatible addresses? I guess there could
be several alternative approaches, including:

  1) remove the IPv4-compatible address support code completely?
  2) leave the code, but surround it with compile-time directives?
      (default-disabled vs. default-enabled is another decision point)
  3) other?

I seem to recall seeing some earlier discussion on this, but perhaps
there are more current viewpoints based on the extensive  scenarios
and analysis work done by 'v6ops'?

Thanks - Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Jun 2004 14:15:08 +0300 (EEST)

> and analysis work done by 'v6ops'?

IMHO, this is probably an implementation choice, and not something we
can or should specify here.  Personally, I see very little use for
them..

-- 
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: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jun 2004 15:37:13 +0200

> can or should specify here.  Personally, I see very little use for

We had a similar discussion around site local and in the end decided that
all the IETF should say is:

    Existing implementations and deployments MAY continue to use this
    prefix.

In other words, it's not our business how implementors choose to
roll back a deprecated feature.

    Brian

---

From: Tim Chown <[email-masked]>
Date: Tue, 8 Jun 2004 15:59:24 +0100

> roll back a deprecated feature.

Right.  My question was just whether covering compatibles was appropriate in
the 6to4 security review.

Tim

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 8 Jun 2004 16:43:06 -0700 (PDT)

> can or should specify here.  Personally, I see very little use for

Agreed there isn't much use for them based on how folks are deploying
or want to deploy IPv6 AFAIK.

Trying to address the 1,2,3 above;
We don't have data that compatible addresses are harmful though.
So I think this means that implementors can remove the support when it
is convenient to them.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 18 Jun 2004 09:25:55 +0300 (EEST)

Hi,

I just revised the draft slightly, as the LC ended a couple of days
ago.

I took about all your comments (also added a note on compatible
addressed but with caveat that it's often still supported).

A few replies in line..

On Wed, 2 Jun 2004, Tim Chown wrote:
[...]
> Do we have field reports of 6to4 abuse to date?  (Curious if they are

Not much has been recorded on this, but there have been a lot of
attacks -- through a relay, not *on* the relay (that I know of).
 
> IPv4 anycast limitation?

I was referring to both v4 and v6 prefix announcements, clarified.

> This is probably why most people see SWITCH's 

To some degree of usefulness, yes.  I could hardly call that an
acceptable level of quality, though -- it's not nice, having to come
to Europe from the US (for example) to talk to your US neighbor...

> are widely implemented - would be very interesting to know...

Yes, I'd be interested in that as well..