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

From: Florent Parent <[email-masked]>
Date: Wed, 07 Jul 2004 11:15:10 -0400

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, [email-masked] 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

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 18 Jul 2004 19:18:42 +0200

> certainly loose ICMPv6 packets. Maybe you are referring to not loosing IPv6 

Indeed, as when one changes an IP address overcoming loosing packets is
not possible in most cases unless one implements sequence numbers which
defies a lot of things. Minimizing the loss though should be an
objective.

<SNIP>

> Again as an option that can be enabled/disabled?

Of course optional, though it should be highly preferred.

There are a number of organisations that require you to change passwords
every 3 months but sending those passwords in clear text is a defacto
use ;)

> saying it should be supported in the protocol?

It could be handy if the protocol could be used for it, then again there
are a number of other established protocols (DDNS for instance) that
could be used here, then again, distributing keys etc is not defined
there thus putting it into this protocol to allow the registration

> > Shouldn't asking the client once be a good option?

The user should be put to the question once if it wants a registered
tunnel or not. If the question is not asked they will not use it.

Greets,
 Jeroen