Subject: Proposed 6to4 work

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Oct 2002 11:35:12 +0200

I'd like to propose that v6ops takes on the following items:

Support for Multicast over 6to4 Networks (6TO4-MULTICAST)
 draft-ietf-ngtrans-6to4-multicast-01.txt
 (to be renamed draft-thaler-ngtrans-6to4-multicast-01.txt)

Security Considerations for 6to4
 draft-savola-ngtrans-6to4-security-01.txt

Any future updates to RFC 3056 and RFC 3068.

  Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Oct 2002 14:32:59 +0300 (EEST)

>  (to be renamed draft-thaler-ngtrans-6to4-multicast-01.txt)

I'm a bit skeptic whether this can be made to work, and the fact that some
200 lines of comments I sent on the list on 11 Jul 2002 went unresponded
didn't exactly help my skepticism..
 
>  draft-savola-ngtrans-6to4-security-01.txt

The draft has focused on trying to spell out the filtering rules that
could be done when implementing 6to4 .. but it takes no stance on "6to4
relay trust" issues.  Those issues could be added if there's some thought
how they can be solved (I can't think of any other than propagating more
specific routes which doesn't seem to be an option).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 10 Oct 2002 08:24:30 -0400

Hi Brian,

>  draft-savola-ngtrans-6to4-security-01.txt

Thanks for the submission.

Dave and Pekka, do you think that these works are ready for consideration
as v6ops work items?

>Any future updates to RFC 3056 and RFC 3068.

Our charter asserts that we would be responsible for any updates
to these RFCs, but I don't know of any specific updates that have
been proposed.  Did I miss something?

For the moment, let's talk about the two documents you listed above.
As those of you who were at the Sunnyvale meeting may recall, we need
to take several steps to accept a document into v6ops.

For a document to become a WG work item, it must:
         - Fit within the WG charter (in the opinion of the chairs)

Itojun and I will confer off-line and give an answer on this ASAP.  But,
in this particular case, let's start the next steps in parallel.

         - Have significant support from the working group, including:
                 - People with expertise in all applicable areas who are 
willing
                   to invest time to review the document, provide feedback, 
etc.

Who has read either of these documents and would like to invest time in
either of them as a v6ops work item?  Obviously Brian.  Are there others?
Please be specific about which document(s) you are willing to work on.
Also, are there folks with multicast and/or security backgrounds who
are willing to review these documents?

                 - Probable (or current) implementors, if applicable

Has anyone implemented either of these I-Ds?  Does anyone plan to
implement them when they are more stable/complete?

         - Be accepted as a work item by a rough consensus of the WG
                 - Should reflect WG belief that the document is taking the
                   correct approach and would be a good starting place for
                   a WG product

Who has an opinion on whether we should/shouldn't accept these
documents as work items?  Please only reply to this if you have _read_
the document(s).  This is not a general question like "should we work
on multicast extensions to 6to4?" or "Is security important?", it is a
specific question about whether or not to accept these documents as
the basis for our work.  Again, please be specific about which document
you are discussing.

Comments on the general approach taken in the documents?  Are they
correct and complete enough that we are ready to move editorial control
of them to the WG?  Authors, what are your opinions?

Also, are the authors willing to serve as document editors if these
documents are accepted?

         - Have corresponding goals/milestones in the charter
                 - Approved by the Area Directors

Itojun and I will work on this if/when the other pieces appear to be
falling into line.

Thanks,
Margaret

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Oct 2002 16:06:55 +0300 (EEST)

I already commented but I'll do so directly and first only on multicast.

> been proposed.  Did I miss something?

From the hip, so to speak,

3056: some nits about security considerations possibly.
3068: possibly whether the ipv4 anycast address can be used as the source 
address when the relay tunnels packets
 
> of them to the WG?  Authors, what are your opinions?

First I'll answer the question you *didn't* ask:  I believe it would be 
good to have "multicast extensions to 6to4" but only if they're 
sufficiently simple and actually workable.

As for the question you did ask, I don't really think the proposed
solution at least currently satisfies these requirements.  At the very
least the applicability would have to be restricted and a few cases that 
make it more complex be cut away.

But if there is sufficient momentum from the others in the w.g., I'm still
willing to work on the draft trying to salvage it.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Oct 2002 16:18:18 +0300 (EEST)

> Dave and Pekka, do you think that these works are ready for consideration

Depending on what v6ops wants.  I believe my security draft is quite 
complete, as far as filtering goes, but if the community wants to extend 
it somehow (e.g. relay issues) that's another thing.

> implement them when they are more stable/complete?

Some of the checks are already in the implementations, but not a complete 
set.  I believe the whole set also will be.

> of them to the WG?  Authors, what are your opinions?

With the current scope, it's quite ready I think.
 
> Also, are the authors willing to serve as document editors if these

Sure.

---

From: Alain Durand <[email-masked]>
Date: Thu, 10 Oct 2002 14:45:50 -0700

>it somehow (e.g. relay issues) that's another thing.
I think the relay issue is very serious but I'm not sure there is any 
satisfying solution.
Documenting it is probably a good start.

There are also some issues aboout RFC3068, as there are very little 
public relays
available today. We need to understand if this is just because we are 
still very
early in IPv6 deployment or if it is because there is a fundamental problem
in the model.

As about multicast, I tend to agree with Pekka, yes multicast would be a 
nice thing to
have, but I think we need first to undertand how critical it is
in the various scenario documents.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Oct 2002 08:30:36 +0200

> Dave and Pekka, do you think that these works are ready for consideration

Regardless of the strict answer to your question, the topics (multicast
and spoofing risks) both need solutions - so sooner or later, we need
to adopt drafts on these topics.

> been proposed.  Did I miss something?

I waiting to see whether we need to add a default MRU to RFC 3056,
following the recent inconclusive discussions. That's the only
thing I know of right now.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: Gert Doering <[email-masked]>
Date: Fri, 11 Oct 2002 09:34:16 +0200

Hi,

> early in IPv6 deployment or if it is because there is a fundamental problem

From what I have heard so far, there may be a couple of reasons:

 - there are only few 6to4 users yet, so the existing relays seem to 
   suffice

 - more and more ISPs are trying to roll out "real" IPv6, so those 
   do not perceive a need to deploy 6to4 in their networks and their
   customer networks (or they just don't even know about 6to4)

 - some people that run "classic" tunnel brokers have experimented with 
   6to4, and have closed down their relay due to abuse reasons (DoS
   attacks against IRC servers) - classic tunnels are easier to trace
   back.   This problem could be solved by having *many* relays, and
   thus making it (maybe) easier to trace back the abuse to the
   source.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  47686  (47095)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: [email-masked]
Date: Wed, 16 Oct 2002 12:27:04 +0900

>public relays available today. We need to understand if this is
>just because we are still very early in IPv6 deployment or if it
>is because there is a fundamental problem in the model.

	as outlined in draft-itojun-ipv6-transition-abuse-01.txt, 6to4
	relay routers
	- are packet laundering services to malicious parties.
	  malicious parties can generate IPv6 packets anonymously by (ab)using
	  6to4 relay routers.
	- can chew up bandwidth of the 6to4 public relay router provider, and
	  there's no way for an ISP to limit accesses to the relay router
	  to their customers (it has to be public service to everyone)

	so ISPs has more risks than benefits in running 6to4 relay routers.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 08:43:51 +0300 (EEST)

> 	as outlined in draft-itojun-ipv6-transition-abuse-01.txt, 6to4
[...]
> 	  to their customers (it has to be public service to everyone)

I believe you *can* quite effectively limit the access.  First by not 
advertising 2002::/16 or 192.88.99.1 to your peers (or doing it by some 
controlled measure, like no-export community), and if it's really 
important, placing some ACL's.

---

From: [email-masked]
Date: Wed, 16 Oct 2002 15:05:09 +0900

>important, placing some ACL's.

	you are correct if you don't have downstream ISPs.

	if you are a big ISP and have downstream ISPs, by doing the above you
	will prohibit your downstream ISPs from providing 6to4 relay routers.
	i'm not sure if it is an acceptable thing to do.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 09:58:43 +0300 (EEST)

> 	i'm not sure if it is an acceptable thing to do.

True, but I believe this is a bit non-issue: if a downstream ISP is
providing the service for everyone, you as a big ISP doesn't really need
to do it that badly (except perhaps as a backup, and then different policy
could apply -- connect the relay with BGP and have the routes be less
preferred) yourself.

---

From: Tim Chown <[email-masked]>
Date: Wed, 16 Oct 2002 09:09:13 +0100

> important, placing some ACL's.

didn't the same lessons get learnt with smtp relays and abuse, leading to
isp's only allowing their own customers to use their smtp service?  is
there a reason to hope 6to4 could be different?

there probably has to be some differentiation between transition tools that can
be used when the isp offers support (e.g. isatap), and the tools used in 
spite of a lack of isp support (e.g. tunnel broker, where some authentication
can, at present, be more easily included if required).  

tim

---

From: Tim Chown <[email-masked]>
Date: Wed, 16 Oct 2002 09:18:50 +0100

> didn't exactly help my skepticism..

I think it is a concern if the home user is possibly going to be a big 
target for 6to4 deployment (if cheap DSL+6to4 routers become available)
and one of the desired delivery methods for certain IPv6 services is
multicast.    But we should also look at Multicast functionality in other
transition tools too.
  
> specific routes which doesn't seem to be an option).

I think all three drafts mentioned by Brian should be taken forward if 6to4 
itself is on the v6ops menu.

Tim

---

From: Gert Doering <[email-masked]>
Date: Wed, 16 Oct 2002 10:35:46 +0200

hi,

> 	  to their customers (it has to be public service to everyone)

It would be possible to restrict access by just not announcing the relay 
addresses (unicast or anycast) into the "public network".

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  48282  (47686)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Oct 2002 16:31:22 +0200

> could apply -- connect the relay with BGP and have the routes be less

The idea was that relays would be run either by cooperatives or downstream
ISPs.  I can't see why a transit provider would want to run one.

The spoofing issue is more serious; I can't see anything but some kind
of ingress filtering to protect against that.

This is why we need a 6to4 security draft in this WG.

   Brian

---

From: Alain Durand <[email-masked]>
Date: Wed, 16 Oct 2002 13:19:58 -0700

Tim Chown wrote:

>there a reason to hope 6to4 could be different
>
This is different.SMTP relay is part of the expected service from an ISP.
6to4 relay is not. One cannot build a deployment model of 6to4
that assumes that the v4 ISP have deployed a 6to4 relay.

    - Alain.

---

From: Alain Durand <[email-masked]>
Date: Wed, 16 Oct 2002 13:27:53 -0700

>of ingress filtering to protect against that.
This won't work. When a 6to4 relay send a packet to the 6to4 world,
it uses it's IPv4 address as source in the outer header.
IPv4 ingress filetering will always let it go through.

When a 6to4 router receive an encapsulated packet on its external interface
that has a native IPv6 inner src address, it can not do any security
checks on the outer IPv4 address, as it can come from any host in the
internet. More, as there is no mapping between the IPv4 src and
the IPv6 src addresses, it is impossible to do any IPv6 ingress filtering.

I fear there is no way to prevent spoofing.

>This is why we need a 6to4 security draft in this WG.
Agreed.

    - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Oct 2002 22:39:15 +0200

I was thinking of IPv6 ingress filtering (i.e. the relay, or the ISP running the
relay, only accepts native IPv6 traffic from legitimate sources). 

IPv4 is only a link layer in the 6to4 context, so you have to treat it
as transparent. Spoofing has to be handled as an IPv6 issue.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 23:40:47 +0300 (EEST)

> IPv4 ingress filetering will always let it go through.

The source IPv4 address could be '192.88.99.1'.  If this was mandated, 
perhaps some checks would be easier.  On the other hand, certain things 
(ones that were also criticized by IESG in Shipworm..) would appear.

That's what it is in our publicly usable (as far from the US and Japan, 
even) relay.
 
> I fear there is no way to prevent spoofing.

See above: it's not complete, but at least it's something.

---

From: Alain Durand <[email-masked]>
Date: Wed, 16 Oct 2002 14:18:18 -0700

>(ones that were also criticized by IESG in Shipworm..) would appear.

How could you make regular IPv4 ingress filtering work?
If you create an exception fo 192.88.99.1, anybody could
impersonate a 6to4 relay, if you don't, packets will
never reach destination...

    - Alain.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 17 Oct 2002 00:33:53 +0300 (EEST)

> never reach destination...

There are no need for any ingress filtering (implementation) exceptions.

Only, you can't run 6to4 relay unless your upstream allows you to use that
IP address.  But that's, in my mind, in line with proper operational
procedures anyway.  It depends much on who's expected to run relays,
though.

With this what we could achieve is that to spoof these packets, the 
spoofer would have to be either in an area where there is no ingress 
filtering at all (ie. core, usually -- and there direct ipv6 spoofing 
would be equally useful) or where it has been explicitly allowed.

The only real problem comes in certain cases if you're using unicast RPF,
I enumerated these a year or so ago in a mail to Brian Carpenter and 
ngtrans.

There are other options, some more scalable than others (like running
multihop eBGP between "trusted" relays and propagating more specifics
between them only -- in this way 6to4 sites could have total control and
there could be a trust relationship between site <-> relay).