Subject: Re: draft-durand-v6ops-assisted-tunneling-requirements-00.txt

From: Pekka Savola <[email-masked]>
Date: Wed, 21 Apr 2004 17:09:10 +0300 (EEST)

Folks --

(co-chair hat on)

 Please send further comments on what you think whether this should be 
 a WG item or not, and optionally why you think it should be an item 
 (or not)?  

 Please do this by next Tuesday, April 27.

(co-chair hat off)

FWIW, I don't have strong personal preference either way; I think we
should move forward from the requirements, and if adopting this as a
WG item would help with that -- fine.  But at the same time I don't
think it is _necessary_ to take up something like this as WG item (at
this point), as it's the result of the requirements that we're anxious
to see, get adopted as WG items etc., and not the requirements
themselves..

On Tue, 13 Apr 2004, Alain Durand wrote:
> I would like to request the wg and is chairs to consider
> draft-durand-v6ops-assisted-tunneling-requirements-00.txt
> as a wg item. I have received a number of comments either privately
> and on the ml, I would like to issue a new revision with a 
> draft-ietf-v6ops title.
> 
> 	- Alain.
>

---

From: "S. Daniel Park" <[email-masked]>
Date: Fri, 23 Apr 2004 22:03:59 +0900

This draft looks good for me and
I second it should be an WG item. 

==========
One question:

4.1 Address Allocation

Why did you restrict the prefix length as /128 ?
Prefix delegation is not considered in this manner ?
In non-authenticated mode, prefix (maybe /64) can
be delegated to its customers IMHO.

==========
with minor editorial comments.

2. Applicability
Althought the main focus of this document is the ISP scenario,
s/Althought/Although

4.4 Security Threat Analysis
The un-authenticated mode relies on out of band authentication.
s/un-/non- (?)

6.8 Phase Out
connecting a customer, there is no reason to keep using tunnels. So
the tunnel-setup protocol must have a provision to enable the ISP to
signal the user to use native IPv6 instead.
s/tunnel-setup protocol/tunnel set-up protocol

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics.

---

From: Alain Durand <[email-masked]>
Date: Fri, 23 Apr 2004 14:37:49 -0700

>  I second it should be an WG item.

Thank you for your comments.

In the current document, /64 prefix allocation is not mandatory.
Our opinion as author was that the non-authenticated mode
was meant to be used in a try-out environment only and
connecting only one node was enough.
In our opinion, any more than that would require authentication.
But this is only one opinion, I would like to get more feedback on this 
point:

Would ISP be willing to deploy IPv6 tunnel service in this 
non-authenticated mode
on production networks?

	- Alain.

---

From: Gert Doering <[email-masked]>
Date: Fri, 23 Apr 2004 23:57:13 +0200

Hi,

> Would ISP be willing to deploy IPv6 tunnel service in this 

Good question.  We certainly are not interested in providing 
non-authenticated (= anonymous?) tunnel services.  

We want/need to be able to backtrace abuse, and (unless I overlook 
anything) this can only be done if we know who setup the tunnel.

On the other hand, we're not a "standard" ISP as we already *do* offer
IPv6 on "standard" products (leased line + ADSL access), so this might
not apply to us anyway.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  60210  (58081)

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

---

From: Pekka Savola <[email-masked]>
Date: Sun, 25 Apr 2004 18:37:03 +0300 (EEST)

Just clarification...

> anything) this can only be done if we know who setup the tunnel.

The "non-authenticated mode" -terminology is confusing, I think.  It 
would be better if we'd be able to find something else.

The question is: would ISPs in general be willing to host a "try-out 
service" which dependended only on the source IPv4 address of the 
hosts?

In other words, would:
 1) IPv4 source address identification be sufficient for ISPs offering 
    this "try-out tunneling" to their own customers _only_, and

 2) same as above, but also to the outsiders (compare to public 6to4 
    relays, but with IPv6 addresses from your pTLA).

My guess is that for 1), the answer would be generally "yes", and for 
2) generally "no".

(That's host we as a NREN would probably react.)

The similar questions could be asked about the "authenticated" mode as
well, of course.  I have a huch that the responses would be similar,
except in a few special cases.

-- 
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: Gert Doering <[email-masked]>
Date: Sun, 25 Apr 2004 18:56:04 +0200

Hi,

> My guess is that for 1), the answer would be generally "yes", and for 

Hmmm, for us as "small and somewhat more flexible commercial ISP", your
guess is right.  Offering a "try-this" service for our customers is 
something we regularily do.  

For "the whole world", it's difficult to justify any additional costs 
this might cause, so the typical answer would be "no".

Gert Doering
        -- NetMaster

---

From: Alain Durand <[email-masked]>
Date: Sun, 25 Apr 2004 14:13:18 -0700

What is the desired level of interaction from an ISP with its IPv4 
customers
to access the new IPv6 service?

The assumption on the draft is that an ISP may be tempted to offer the 
service
as a try-out to any of _its_ customer without asking anything, no 
registration, no fees,
no tracking, no guaranty, no nothing. The so called 'non authenticated' 
mode
(I should rename this 'non-registered' mode) was design for that.
The draft also made the assumption that for anything more production 
oriented,
ISPs would like to see some kind of registration, at least for logging 
perspective.

Supporting two modes of operation certainly add complexity, so the 
question is,
is it worth it? Is there a real need from ISPs to offer this non 
registered mode?

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 26 Apr 2004 00:18:55 +0300 (EEST)

On Sun, 25 Apr 2004, Alain Durand wrote:
[...]
> question is, is it worth it? Is there a real need from ISPs to offer
> this non registered mode?

One could also (IMHO) ask whether there are cases when the ISP would 
only want to offer non-registered mode.

In some networks where the ISP is capable of offering dual-stack
access or other kind of tunneling methods (e.g., L2TP as described by
Gert), the only interest from the ISP side could be this "zero
infrastructure -- zero hassle" mode -- non-registered.

To me, both seem to be applicable but in different context:  
non-registered is an auto-discovered or a "tryout" thing, or meant for
short-term fix.  Registered seems like a more long-term solution for
an ISP which is serious about v6 but cannot/will not offer dual-stack
services for whatever reason yet.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sun, 25 Apr 2004 23:32:58 +0200

In addition to that I will say that the ISP could be also interested in offering the service non only to _its_customers but also to:
- _its_customers when traveling
- _other_customers in order to convince them about the service and gain then

I still feel that non-authenticated is acceptable ;-), specially because is a clear contraposition to the authenticated mode. Unless we agree that the correct denomination is registered and non-registered modes ?

Whatever is the final name, I really believe that both modes are a must.

Regards,
Jordi

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sun, 25 Apr 2004 23:36:04 +0200

Agree ... actually I believe I mention this case in the sense that a non-registered mode is very easy to implement, same as a 6to4, and ISPs could only go to offer this if adds not overload to their work.

I know ... the workload can come by abusers of the service, but some times is much easier to have a non-registered service and then either allow the service only in "own" network or filter offending users, or whatever.

Regards,
Jordi

---

From: Alain Durand <[email-masked]>
Date: Sun, 25 Apr 2004 14:32:04 -0700

Pekka,

I understand what you are saying, but are you speaking
as an ISP, a wg participant or as the wg chair?

	- Alain.

---

From: "S. Daniel Park" <[email-masked]>
Date: Mon, 26 Apr 2004 11:41:51 +0900

> Supporting two modes of operation certainly 
> add complexity, so the question is, 
> is it worth it? Is there a real need from ISPs 
> to offer this non registered mode?

Well, *real need* is so difficult to mention in the 
ISP aspect. I guess ISPs don't like to do it as 
non-registered mode whether it is try-out phase 
or not. If this draft is for requirements, it is not
bad to describe both at this stage.

---

From: Jeroen Massar <[email-masked]>
Date: 26 Apr 2004 09:04:57 +0200

> would be better if we'd be able to find something else.

I would call that "Anonymous". But I would provide the 'client' with
a cookie or something similar so that they can pass the cookie to you
when they come back and thus allowing them to get the same prefix they
had before.

>     this "try-out tunneling" to their own customers _only_, and

This indeed works for most ISP's. They can do this by filtering based on
the request made or simply by putting a firewall on the service endpoint
and thus filtering out anything unwanted.

>     relays, but with IPv6 addresses from your pTLA).

Anonymous is done by many ISP's already, at least if you look at a TB
being a anonymous service; Freenet6 is probably the best answer here.

> My guess is that for 1), the answer would be generally "yes", and for 

Correct.

> except in a few special cases.

It actually all depends on one simple thing: money.
If an authenticated user does pay why shouldn't you give service to them
even if it is somewhere else. Though such policies are mostly ISP based.

Greets,
 Jeroen

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 26 Apr 2004 06:19:13 -0700 (PDT)

> Would ISP be willing to deploy IPv6 tunnel service in this 

I can see this depending on what other authentication is taking place.
For instance, if e.g. Radius authentication occurs before the IPv4 address
is assigned to the customer, the tunnel setup protocols does return
routability check, and the ISP protects the routing of their addresses
(e.g. using route filters at their edges) then why doesn't the IPv4 address
provide sufficient proof (after the return routability check) that
the user is indeed the user that was authenticated using Radius?

So it might be that explicit authentication of the tunnel
setup is only needed when
1) there wasn't authentication for the IPv4 setup, or the tunnel
   server can't extract the user id from system based on the IPv4 address
2) the infrastructure between the tunnel server and the client isn't
   trusted (which might be an argument for using IPsec tunnels in
   addition to authenticating the tunnel setup).

Thus it is far clear for me that what you call unauthenticated setup is
that limited (it is "not explicitly authenticated" IMHO since there
might be IPv4-related authentication that can be reused).

One other minor comment on the document;
In section 2 it talks about "customer owned NAT".
I think the issue applies whether the NAT is customer or ISP owned and
controlled. Even for an ISP owned and controlled NAT the ISP might not want
to upgrade the NAT to be more friendly to IPv6 (e.g. by supporting tunneling
on the NAT itself) since that might be expensive.
Thus I think it makes sense to state that the NAT might belong to the customer
or the ISP in section 2.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 15:49:09 +0300 (EEST)

(co-chair hat on)

As there was slight preference to having this as WG item, and it is
very important to gain consensus on the requirements for a tunnel
server solution, please publish the next revision under 
draft-ietf-v6ops -label, making this a WG item.

The WG participants are already urged to review and provide feedback
on the document.  If you want to "catch" this revision cycle, please
send your comments by next Wednesday, 5th May.

The intent is to WG last call it after having been published as WG
item, and reach WG consensus on the requirements within a month.

Thanks!

(co-chair hat off)

---

From: Jeroen Massar <[email-masked]>
Date: 30 Apr 2004 16:36:49 +0200

> send your comments by next Wednesday, 5th May.

You have my 'vote' too for making this document a WG item.

My comments:

4 mentions "(initial tryout)" is that in the wording of "try
unauthenticated first, then authenticated" or is it meant for something
else? 4 also mentions that the 'unauthenticated' mode can be aimed for
tryout. Does this mean that using source IP is 'authenticated'?

4.2: The 'non-authenticated' part should be taken away here as it should
also be available for authenticated modes. Eg user knows his user/pass
for the ISP and then runs the tool(tm) or automatically, tool pops up
and notices "I automatically found Example ISP, can you login"?

4.4: s/victim's uplink/victim's downlink/
or better 'link' as it can be done two way.

Though I do not know of many protocols that will actually send a lot of
traffic to a host without asking for a ack every now and then ;)
Multicast is not that widely deployed unfortunatly though that would
still ask for keepalives from the 
One base item of course: ingress filtering, to which I would also add
that the Tunnel Servers should do egress filtering, limiting what the
tunnel can send onto the internet unless there is an agreement with the
ISP that it is allowed to send other prefixes. Note that this is
currently a big problem in the IPv6 Internet, where a lot of ISP's allow
any prefix to be sent onto the internet -> spoofing, not only 'transit'.

Also in 4.4:
s/IPv4 return routability checks/IPv6 return routability checks/

I like the 'clear text password is out' btw. IMHO MD5 suffices for most
setups, SHA1 or up could be used instead, there thus should be a
possiblity to select a authentication protocol.

Greets,
 Jeroen