On Mon, 2004-06-28 at 21:31, Internet-Drafts@ietf.org wrote:
<SNIP>
> A URL for this Internet-Draft is:
> 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
Attachment:
signature.asc
Description: This is a digitally signed message part