[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Hi Jeroen,

Sorry for long round-trip. Back from vacation.
comments inline:

-- On Tuesday, June 29, 2004 10:16:34 AM +0200, Jeroen Massar wrote:

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'.

ok.


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.

"User Equipment". From [3GPP] draft.


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.

The previous version specifically mentionned that /128 was assigned on the tunnel link. We changed that saying that a /128 must be supported in any mode, but a prefix (/64 and +) is possible in any mode as well. How this prefix is assigned is unspecified in this draft.


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.

RFC 3177 already mentions that.

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....

How about adding text relating to RFC3177? I'm not sure forbidding /128 in the protocol is the right direction, but I'd like to hear from others as well on this.


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

ok. noted.


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.

That is certainly more related to the implementation (as with other parts of this draft as well).

Also "not _an_ exhaustive list" which it indeed is as many things can
be added.

Agreed.


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.

I don't think ip-proto-41 should be forbidden because of possible spoofing (otherwise, we'll have to forbid IPv4 and IPv6 usage ;-)

If spoofing is a security risk for an ISP, then security measures are available from other protocols, such as ipsec, no? (or ayiya ;-)

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.

Noted. Yes, I can help to slow down the DoS. Return routability also helps against attacks based on IP spoofing.

...


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'

ok. noted.


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.

as stated above, I'm not (yet) convinced of that. I can certainly see a "secured" tunnel mode, but as an optional feature.

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.

Agreed and the requirement doesn't propose that. The security policy could allow IPv6 in UDP for example, but not ip-proto-41. In which case the user must be able to select the encapsulation type.


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.

Yes. But "without loosing packets" need to be defined. e.g. if I have a ping(v6) in a loop going out of my tunnel and the NAT state changes, I will certainly loose ICMPv6 packets. Maybe you are referring to not loosing IPv6 connections instead?


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.

Again as an option that can be enabled/disabled?


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.

ok. Similar to the registration (4.2) information I guess.

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.

The current requirement has nothing about DNS prefix delegation. Are you saying it should be supported in the protocol?


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

Not following here.


"- 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 ?

The requirements doesn't go as far as selecting how it's implemented.

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?

The purpose was to state the requirements to have a clean table to work on. TSP is an existing implementation that fulfills most of these requirements, but I'm biased ;-)

Florent