Subject: I-D ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-00.txt

From: [email-masked]
Date: Mon, 28 Jun 2004 15:31:47 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Requirements for assisted tunneling
	Author(s)	: A.Durand, F. Parent
	Filename	: draft-ietf-v6ops-assisted-tunneling-requirements-00.txt
	Pages		: 0
	Date		: 2004-6-28
	
This document defines requirements for a tunnel set-up protocol that
   could be used by an ISP to jumpstart its IPv6 offering to its
   customers by providing them IPv6 connectivity without having to
   upgrade its access network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-assisted-tunneling-requirements-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 29 Jun 2004 10:16:34 +0200

On Mon, 2004-06-28 at 21:31, [email-masked] wrote:
<SNIP>

> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-00.txt

My comments:

Section 1.
8<---------
    "Assisted tunneling" is used in this document to described a
     transition mechanism where the parameters"
--------->8

Should be 'describe'.

Section 2.
8<---------
    dual stack UE connecting to IPv6 nodes through a 3GPP network that
--------->8
What is the definition of a "UE" ? User Endpoint I assume or this
more likely to be some 3GPP term of which I am not familiar with.

Section 4.1
8<---------
   Assignment of an IPv6 address (/128) to the end-node must be
   supported in both modes.
--------->8
Shouldn't we suggest assigning a /64 over 'links'? Tunnels are 'tunnel-links'
between the TunnelServer and the TunnelClient.

Also what if the client moves to a native link. There could be the case where
a ISP only can't provision the last mile, eg because the router directly
facing the customers doesn't support IPv6 yet. In this and some other cases
when the router and the CPE does support IPv6 they can simply lay the /64
tunnel space on the native link and the user nor the ISP have to change much.

Also mentioning that ISP's can pass out /128's will cause them to do so and
also will have them have a word saying 'see that RFC they say give out /128's.
Giving out a /64 for a link doesn't mean one can't filter everything except
::1 and ::2 of that /64 btw (or just set a /128 only to the remote side).
Read: with /128's IPv6 NAT will happen....

Section 4.4
This could refer to draft-palet-v6ops-tun-auto-disc

Section 4.7
Isn't this all out of scope for the setup protocol ?
It is good to mention them nevertheless of course but still.
Also "not _an_ exhaustive list" which it indeed is as many things can
be added.

Section 4.8
Though no direct solutions are refered to, this could also mention that
proto-41 should not be used as it doesn't get authenticated per packet
and thus can easily be spoofed when the access network (client<->server)
isn't completely under ingress/egress filtering control, aka when the
IPv4 or outer when talking about IPv6-in-IPv6 etc, addresses can be spoofed.
A mention of shaping tunnels, eg ratelimiting per /24 destination IPv4
could also help in cases where somebody tries to DDoS, of course these
are preventive measures that can be circumvented, by ddossing the router
upstream etc.

Section 5.1
How big is a 'typical broadband ISP'. Is this 100 sites? 10k? 100k ?

Section 5.2
Like 4.4, this could refer to draft-palet-v6ops-tun-auto-disc
Prolly the 'best' is to have:
 - dns prefix search (tunnelsetup.example.net)
 - globaly known single anycast address where
   the setup protocol connects to and asks for service.
   This anycast address could either say 'see http://www.example.net/ipv6/'
   or it could say 'no service' or 'get your setup info from host tunnelsetup.example.net'

Section 5.3
This basically boils down to using UDP, as I think it should be a requirement
to demand per-packet authentication of these tunnels packets to work against
spoofing, proto-41 is really a no-go. This also saves for the overhead of
figuring out 'are you behind a nat' and 'are you behind a firewall'.
If an administator is filtering certain ports/protocols then that should never
be tried to be circumvented.

Section 5.4
Some NAT boxes will force-timeout mappings or have a very short timeout.
The tunneling or the setup protocol used should be able to recover thus
from both endpoint address and port changes without loosing packets.

Section 5.5
The latency issue for the config protocol basically means that any tunnel setup
protocol employing command/response should be able to support some mechanism
similar to SMTP pipelining. SASL auth defeats the initial setup of course.
As can be learned from TSP the overhead is not that large at all thus this
should be mostly ignorable. Good to note nevertheless.

Section 5.6
8<-------
   The tunnel set-up protocol must not introduce any new vulnerability
   to the network.
-------->8
Shouldn't that read:
8<---------
   The tunnel set-up, nor the tunneling protocol must not introduce
   any new vulnerability to the network.
--------->8
When you only 'secure' the set-up, then people will simply abuse
the tunneling protocol.

To also mitigate attacks based on 'knowledge' of endpoint information eg
by sniffing setup information packets it should be IMHO that the tunnel
setup protocol is able to use some form of SSL/TLS mode thus making sure
that the interaction between client and server is not readable maybe
disclosing information that can be useful to attack the tunnel.

Section 5.8
Additionally the protocol should have the generic possiblity of returning
a URL. This can be used in many cases:
 - signup page
 - help page
 - explaination page
 - 'this service is closed'
 - etc.
It could also explain the user how to disable the client program.
The client-program might also want to ask the user if it wants to use native
or tunneled connectivity maybe in case where the native connectivity is
misconfigured, and thus not working.

Section 5.10
Fortunatly this is a should, typically, from what I have seen at least,
most ISP's don't allow their customers to change reverse DNS entries.
Also, tunnels should be seen as 'transit networks', the /48 routed to the
client should have a means of registering dns servers though.

Appendix A
"The registered mode:"
"- implementation SHOULD turn it off by default"
Shouldn't asking the client once be a good option?

"- MUST support single address assignment"
/128 or /64 ?
Remember, that when learning people they can give /128's there will be NAT
again for IPv6 and why oh why did all these nice people invent IPv6 ? :)
See also above at section 4.1

"- MUST support prefix delegation...."
As there was a mention of not reinventing the wheel, should this be using
DHCPv6 or RA's ? Also the client-utility can't know what the network of
the user looks like. Must a prefix also always be a /48? We might want to
suggest that here to make sure ISP's adhere to that (yup trying to 
technically enforce a political policy ;)

Next to that, as I see a number of items that do not directly relate to TSP,
is there a totally revamped TSP draft or a totally new protocol in the pipe?

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Tue, 29 Jun 2004 09:39:28 -0700

Jeroen,

Thank you for your comments. I'll get back to them later this week I'm 
on a businees trip.

>is there a totally revamped TSP draft or a totally new protocol in the pipe?
The later.

    - Alain.