Subject: RE: zeroconf draft

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Mon, 23 Aug 2004 13:04:27 +0200

Hi Pekka,

Thanks a lot for your thorough, and much appreciated, comments.

My responses inline (editor hat off).

BR, Karen

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Friday, August 20, 2004 12:43 PM
> To: Karen E. Nielsen (AH/TED)
> Cc: [email-masked]
> Subject: Re: zeroconf draft 
> 
> 
> On Thu, 19 Aug 2004, Karen E. Nielsen (AH/TED) wrote:
> > Enclosed please find a first draft detailing the goals of 
> zero configuration tunnelling as
> > seen by the authors.
> 
> Thanks!
> 
> I really hope people will read and comment.
> 
> Below are my quick personal thoughts on it.
> 
> First, a couple of generic observations:
> 
>  a) the doc aims to be generic enough while being 
> sufficiently well grounded
>  in the 3GPP requirements.  That's IMHO a good thing, but some of the
>  applicability assumptions in section 4.1 seem t be specific to 3GPP.
> 
>  For example, if you consider an ISP which wants to provide 
> v6 tunnel to its
>  own customers, and not upgrade the access network/CPE 
> routers, the no-NAT
>  assumption does not hold.  The assumption for source address 
> spoofing/site
>  protection might also be slightly different, but I 
> understand that at least
>  some ISPs do in fact ingress filter their home customers, so 
> that might be
>  an acceptable tradeoff here.
> 
>  My personal preference would be to take out the no-NAT 
> assumption from the
>  bullet list, and maybe later in the section or as a new section say
>  something like:
> 
>   In some environments (e.g., 3GPP tunnelling), it can be 
> assumed that there
>   is no NAT on the path.  In some other environments, (e.g., 
> ISP providing
>   IPv6 tunnel to its own customers instead of upgrading the 
> access network
>   or CPE devices), there may be one or more NATs in the path.
> 

The starting point of the document has been 3GPP and
no other applicability environments have explicitly been identified,
nor considered, in the initial phase of this work.

The reason for this has been not to loose focus from the 3GPP particularities
(constrained conditions) as well as to stay with a minimal set of goals. 
(See scope discussion below.)

As stated in the introduction "the applicability of Zero-configuration 
tunneling may widen to other transition scenarios". Identification of such
applicability environments and possibly (perhaps) tuning of the goals is what could start now.
(See below on the scope).

At present, we are not attempting to pass the document of as more generic than this.

Scope discussion:

We set fort to identify the set of goals of a simple, minimalistic tunnelling
mechanism. For my, the following has scoped the goals

1. must meet the constrained conditions of the 3GPP
2. only a limited set of goals required in the 3GPP environment, 
this by virtue of the many assumptions that can be made. Lets start with this set and
see how far this gets us.
3. Only limited set of IPv6 connectivity functions is required, i.e., not full suite of [7], [8] and [9].
(Yes, this needs to be clarified also in terms of services, applications)
4. 3GPP timing issue
5. Other scenarios are served by assisted tunneling [5]. Assisted tunneling do not meet
the needs of 3GPP.

Now, (some of) the questions to me are the following:

* which other scenarios are served this set of goals ?
* which scenarios other than 3GPP are not served by assisted tunnelling - and
of those:
   - which scenarios could be served by zeroconf if the goals were slightly extended
     while sustaining 1. and 4. (bu 1. the set of goals can not be minimalized if 3GPP should be served)
   - which scenarios are neither served by zeroconf nor by assisted tunnelling (perhaps not
my personal interest, but something that needs to be solved)
* where do we cut the line in between zeroconf and assisted tunnelling, and e.g. 
are NAT traversal required in both or can that be something you have to go for assisted tunelling for ?

>   b) The document does not mention the goals for what kind of 
> services the
>   users must be able to use (instead of just the basic set).
>   For example, is multicast envisaged as something that 
> should be supported?

Agreed. Should be clarified.

> 
>   c) the name "zero-conf tunneling" should probably be something 
>   better, but that's just semantics, not something we need to worry 
>   about right now.
>  
> more substantial
> ----------------
> 
>    The scope of zero-
>    configuration tunneling is not to provide emulation of the 
> full suite
>    of native IPv6 connectivity functions; rather the focus is on
>    providing a minimal set of features required for automatic
>    establishment of IPv6 connectivity.
> 
> ....
> 
>    For scenarios demanding advanced tunneling features, for 
> example full
>    emulation of native (though tunneled) IPv6 connectivity, a 
> more full-
>    fledged tunneling mechanism is envisaged to be deployed, see [5].
>    With respect to the latter, an analysis of appropriate 
> mechanisms for
>    automatic discovery of the tunnel endpoint is being done in [6].
> 
> ==> I'm confused your use of "full suite of native IPv6 connectivity
> functions" in about 3 different places.  What are the actual functions
> of native v6 connectivity?  Typically neighbor discovery and route
> advertisements.  But you run or can run all of these on top 
> of that link,
> right? 
> 
> In other words, what you're probably intending to say that 
> the aim of this
> tunneling is to provide a simple suite for v6-in-v4 tunnel 
> establishment,
> not the full, most comprehensive solution to v6-in-v4 
> tunneling.  It's an
> IPv6 link, so IPv6 should work on it without issues, right?
> 

I agree that this should be better spelled out in the document.

The full suite is however in the Scope Section referred to
as the functions identified in [7], [8], and [9], so it is not totally unqualified.

Anyway the goals specify what is actually required, namely one /128 address and
something comparative with IPv6 NUD. 

Whether it should say RFC 2461 (or comparative to 2461) is debatable, I think.
The individual solution should specify exactly how it comply with RFC 2461, in the
same manner as this has been done in RFC 2893, mech-02 and RFC 3056.

It is very easy to say "so IPv6 should work on it without issues, right?"
- What do you mean by "IPv6" here ? 

> 6.3. Use native when available
>                                                               
>                                            
>    The tunnel protocol should allow the usage of native IPv6
>    connectivity whenever such is available.
>                                                               
>                                            
>    The protocol must in no way restrict the native IPv6 
> capabilities of
>    the client node.
>                                                               
>                                            
>    IPv6 native connectivity must be preferred if available.
> 
> ==> I'm concerned of the last goal.  I agree that an 
> "automatic sunset" is
> preferable, but this creates complexity on the node (maybe 
> not fulfilling
> the other goals), as it requires that some process monitors 
> which route
> advertisements or other indications of IPv6 connectivity are 
> available over
> the native interface.
> 
> Maybe you meant, "The tunnel should [or must] not be 
> established if native
> IPv6 connectivity is available", i.e., make it a set-up time 
> issue only?

I agree.
> 
> 6.7. Tunnel Link Sustainability
>                                                               
>                                            
>    The tunnel link established in between a host deploying zero-
>    configuration tunneling and an associated tunnel server should be
>    expected to remain in administrative active state for the 
> duration of
>    the validity of the IPv6 address provided to the host.
>                                                               
>                                            
>    The tunnel protocol must not mandate keep-alive messages to be
>    transmitted by the host simply in order to sustain tunnel link
>    connectivity.
> 
> ==> I'm not sure how well this goal is grounded in the actual 
> requirements,
> i.e., what is the reason for this goal?  Do you find having to send
> keep-alive messages unacceptable due to their packet overhead 
> (if small) in
> constrained environments, for example?   If that's the case, 
> please say
> so :).
> 

I agree. 
The bandwidth issues is the point here and we should motivate this goal.

> ==> this brings other two points: 1) how does the client know when the
> tunnel no longer works if there are no keepalives (the router 
> could die, the
> client could move to another network which cannot tunnel to the tunnel
> server etc.), and 2) how does the server perform garbage 
> collection (if
> applicable) on the users.
> 

What we try is to say that is that no pro-active measures should need
to be taken by the hosts/servers to maintain link-sustainability. This doesn't mean
that re-active measures cannot be taken and we explicitly state that mechanism
comparative to NUD should be available for this purpose.

How the server performs garbage collection, if stateful, 
is up to the implementation I would assume.

> (you already mentioned NUD in sect 6.8)
> 
>    Given that all IPv4 sources of proto-41 tunneled packets can be
>    assumed to be legitimate, threats stemming from 
> encapsulated packets
>    sourced by nodes (addresses) other than nodes (addresses) which the
>    end-hosts recognize as tunnel servers (identified by 
> addresses) can,
>    if not already an intrinsic part of the zero-configuration 
> protocol,
>    easily be mitigated by the implementation of appropriate
>    differentiated (source addresses) drop policies in the end-hosts,
>    i.e., accept only if source is tunnel server.
> 
> ==> wouldn't such a "mitigation" possibly break the protocol 
> (depending on
> how it's written), i.e., if the protocol includes direct 
> encapsulation, the
> nodes would have no other way of talking to each other than 
> through that
> encapsulation (i.e., you'd have a more specific prefix on the 
> interface, and
> default route towards the server -- if the more specific prefix
> communications fail, at least standard ND sending algorithms 
> wouldn't even
> try to send towards the default route)?
> 
> So, it would seem that if the protocol includes legitimate 
> node-to-node
> communication, such mitigation would break the node-to-node 
> communication
> and would be unacceptable.

First of all the security section, as clearly stated in the beginning, refers
to the router-host communication case only.

Secondly, I think that we should have said "could" here instead of "can".
We are merely pointing to a possible solution space for the router-to-host solution. 

A direct tunnelling solution may have to turn to other means. 
But again as said in various places we are not explicitly considering the host-to-host
direct tunnelling solution in this document. Were we to do that, I agree with your comments.

> 
> 8.2.2. Threats to tunnel servers
>                                                               
>                                            
>    No specific threats to the tunnel server have been identified.
> 
> ==> resource exhaustion might provide a few, even if these 
> are not attacks
> as such; if the tunnel server must keep state, that state 
> could go up.  Or
> if the tunnel server is hosted to provide connectivity to a 
> large number of
> nodes, the traffic they send could go up and trash the server.
> 
> By proxy, would this call for adding a goal for being able to 
> distribute the
> tunnel server load among multiple tunnel servers?
> 

I believe the first is the general case with nodes implementing stateful
mechanisms (as e.g. NAT) - it is not particular to the fact that the node is
a tunnel server, wherefore we haven't mentioned it as a specific threat.
But we may do so to avoid confusion.

I believe the second is a valid point for all nodes processing 
a high amount of traffic (e.g. routers). 
Load balancing among multiple router weren't part of base IPv6, but it may 
become so (<draft-ietf-ipv6-host-load-sharing-02.txt>). 

Load balancing could be good, whether its really required by this 
miminal function, I am not sure.

Have to run, will respond to the editorial below subsequently.

Thanks again,
Karen

> 
> 
> editorial
> ---------
> 
>    Tunnel endpoint:
>    A dual-stack node performing IPv6-in-IPv4 tunnel
>    encapsulation/decapsulation in accordance with zero-configuration
>    tunneling.
> 
> ==> is Tunnel Server also a Tunnel endpoint?  That is, should 
> we define
> "Tunnel Client" as well if tunnel endpoint is meant to be a 
> generic term?
> 
>    Tunnel Server:
>    A dual-stack server node with native IPv6 connectivity and which
>    provides IPv6 connectivity to client nodes by performing 
> IPv6-in-IPv4
>    tunnel encapsulation/decapsulation to/from client nodes in 
> accordance
>    with zero-configuration tunneling.
> 
> ==> as a pedantical note, native v6 connectivity is not a 
> strict requirement
> for the tunnel server.  It could very well get its v6 
> connectivity through
> v6-in-v4 tunnels, right?
> 
>    extendable to outer encapsulation mechanisms, e.g., IPv4-in-IPv6.
>                                                               
>                                            
> ==> s/outer/other/
> 
>       - Network infrastructure nodes cannot in an attempt to 
> protect the
>         end-hosts by default filter out intra-site (i.e. internally
>         sourced and destined) ipv6-in-ipv4 tunneled packets.
>       - As the tunnel service is un-authenticated (not registered) the
>         tunnel server may be usable to reflect tunneled 
> packets into the
>         network, similar to the 6to4-reflection attacks identified in
>         Error! Reference source not found..
>       - The usage of zero-configuration tunneling may open up for
>         threats to other mechanisms in the network that rely 
> on proto-41
>         encapsulation.
> 
> ==> could these be reworded slightly?  In each "bullet", 
> there appear to be
> a few grammatical errors which make it difficult to 
> understand the intent of
> the bullets.
> 
>    In order for an end-host deploying zero-configuration tunneling to
>    trust that packets it perceives as stemming from tunnel servers do
>    actually also stem form such as well as for the end-host 
> to trust on
>    the benevolence of its tunnel servers it suffices that a 
> sufficiently
>    trustworthy tunnel server end-point discovery mechanism, read
>    discovery of benevolent tunnel servers IPv4 address(es), is
>    implemented.
> 
> ==> I had hard time parsing the first lines of this loooong sentence
> 
> 10. Authors Contact Information
> 
> ==> "Authors' Addresses"
> 
> 11. References
>                                                               
>                                            
> ==> splitting the refs to normative/informative might not hurt..
> 
> 
> 
> 
> -- 
> 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: Pekka Savola <[email-masked]>
Date: Tue, 24 Aug 2004 08:50:16 +0300 (EEST)

> (See scope discussion below.)

Agree, but I don't think the number of goals need to go skyrocket if 
similar, related scenarios would be added.

> 5. Other scenarios are served by assisted tunneling [5]. Assisted
> tunneling do not meet the needs of 3GPP.
> 
>      while sustaining 1. and 4. (bu 1. the set of goals can not be
>    - which scenarios are neither served by zeroconf nor by assisted
> tunnelling (perhaps not my personal interest, but something that
> needs to be solved)
>
> * where do we cut the line in between zeroconf and assisted
> tunnelling, and e.g.  are NAT traversal required in both or can that
> be something you have to go for assisted tunelling for ?

The assisted tunneling as of right now has two modes: "managed" and 
"simple".  Simple is very close to the requirements with this 
zero-conf work.  It would be artificial to separate these, as both aim 
to address the same problem: providing v6 simply, over an unupgraded 
access network.

My concern is that we are looking at the two almost identical problems
from isolation.  IMHO, it would seem to be much better to merge the
"simple" part of "assisted tunneling" with zero-conf work, and
re-share assisted tunneling to just list the requirements for more
heavy-weight and "managed" type of tunnels (like L2TP, TCP/PPP, TSP,
etc.).

In other words, rather than looking which goals are listed under the 
assisted tunneling document, we should rather try to figure out what 
would be the right place to list them.  This would seem to be as good 
as any, and that remove the artificial division between zeroconf and 
assisted tunneling.

Initially, it was thought that 3GPP scenarios would have been suitably
addressed by the simple mode of the assisted tunneling, but you guys
felt it was better to have a separate document; that's fine, it seems
to me that such a document should include all the related, similar
scenarios.

> The full suite is however in the Scope Section referred to as the
> functions identified in [7], [8], and [9], so it is not totally
> unqualified.

OK.
 
> Anyway the goals specify what is actually required, namely one /128
> address and something comparative with IPv6 NUD.
> 
> Whether it should say RFC 2461 (or comparative to 2461) is
> debatable, I think. The individual solution should specify exactly
> how it comply with RFC 2461, in the same manner as this has been
> done in RFC 2893, mech-02 and RFC 3056.
>
> It is very easy to say "so IPv6 should work on it without issues,
> right?" - What do you mean by "IPv6" here ?

*Anything* which uses the protocol IPv6.  For example, if you take a
manually configured tunnel, *everything* (AFAICS) which uses IPv6 and
works solely from layer 3 and up works on top of that tunnel, except
possibly future mechanisms which might try to map the IPv6 address
somehow to the lower-layer address (e.g., consider SEND or PANA
extensions).

For example, whether you can run DHCPv6 for addresses or PD, whether
you can run IPv6 multicast, whether you use SEND, etc. -- in summary,
whether you're restricted to a specific subset of functions that have
been specified for IPv6, and whether you'll be able to leverage future
extendibility.

I'm not sure which words to use to describe this situation, but I 
personally feel it's pretty important, because this could set very 
tight requirements on the applications folks may wish to deploy now or 
later, or deployments in more general.  

> > ==> this brings other two points: 1) how does the client know when
> > the tunnel no longer works if there are no keepalives (the router
> > could die, the client could move to another network which cannot
> > tunnel to the tunnel server etc.), and 2) how does the server
> > perform garbage collection (if applicable) on the users.
> > 
> 
> What we try is to say that is that no pro-active measures should
> need to be taken by the hosts/servers to maintain
> link-sustainability. This doesn't mean that re-active measures
> cannot be taken and we explicitly state that mechanism comparative
> to NUD should be available for this purpose.

Does NUD count as proactive measure?  You can consider it both ways, 
if it probes about every 30 seconds if there hasn't been traffic.

> > node-to-node communication, such mitigation would break the
> > node-to-node communication and would be unacceptable.
> 
> First of all the security section, as clearly stated in the
> beginning, refers to the router-host communication case only.
> 
> Secondly, I think that we should have said "could" here instead of
> "can". We are merely pointing to a possible solution space for the
> router-to-host solution.
> 
> A direct tunnelling solution may have to turn to other means.  But
> again as said in various places we are not explicitly considering
> the host-to-host direct tunnelling solution in this document. Were
> we to do that, I agree with your comments.

This is already discussed in another thread, but I think the key point
here is *node-to-node* communication, not direct tunneling as such.

> > ==> resource exhaustion might provide a few, even if these are not
> > attacks as such; if the tunnel server must keep state, that state
> > could go up.  Or if the tunnel server is hosted to provide
> > connectivity to a large number of nodes, the traffic they send
> > could go up and trash the server.
> > 
> > distribute the tunnel server load among multiple tunnel servers?
> 

Right.
 
> a high amount of traffic (e.g. routers). 

As noted in the message to Jordi, I'd be concerned if one would be 
concerned about the amount of state, not the amount of traffic.

> Load balancing among multiple router weren't part of base IPv6, but
> it may become so (<draft-ietf-ipv6-host-load-sharing-02.txt>).
> 

Just to be clear, I wasn't describing load-balancing as described in 
draft-ietf-ipv6-host-load-sharing-02.txt (which wouldn't probably even 
work nicely, at least if you don't make assumptions about the 
solution).

I think the goal here is that you'll be able to deploy multiple
"tunnel servers", and be able to somehow make some of the hosts to use
tunnel server A, some B, others C.  You probably don't want all the
hosts sharing the load equally among servers A to C (which is what the
load sharing spec says).  In short, this probably turns out as a 
requirement for the auto-discovery of the tunnel server, as Jordi 
noted, but it should be explicitly discussed.

(In other words, you're concerned of seamlessly being able to deploy 
multiple tunnel servers to be able to support a larger amount of 
tunnel end-points.)

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Tue, 24 Aug 2004 09:50:29 +0300

Pekka, Karen,

> to me that such a document should include all the related, similar

This, of course, has been a sticky point from the beginning. There seems
to be two schools of thought: One saying that assisted tunneling's
simple mode would fit the 3GPP scenarios. The other is saying that
assisted simple mode does not fit the requirements of 3GPP. Thus, an
additional document was decided to be created to see if the requirements
are the same instead of artificially putting the two possibly
distinguished set of requirements into the same document.

I believe if the scope is kept well and not bloating the document with
non related requirements we can do the analysis of the two set of
requirements and see of the two sets are equal. 

So, from my perspective I think it is important that the scope of the
document is kept narrow instead of over widening it. 

> later, or deployments in more general.  

Are you saying that everything that is supported by native v6 (e.g.
multicast) must be supported by the tunneling mechanism, or are you
stating that if something is not required it should be explicitly
documented? 

> if it probes about every 30 seconds if there hasn't been traffic.

The problems of the keep-alive mechanisms over wireless links are
battery consumption, radio resource reservation, and depending on
operator's business model cost. The first two I would personally
consider as the main problems. 
If the terminal has to keep the tunnel alive, would it mean that it has
to wake up the radio periodically (even when it would not need it
otherwise) send a packet over the radio and possibly wait for answer.
This means that it cannot be in a "dormant" mode all the time it's idle.
This consumes battery quite a bit. In addition, it reserves radio
resources for the sending of the keep-alive unnecessarily.

> here is *node-to-node* communication, not direct tunneling as such.

Maybe I'll find the definition in the other thread, but I don't really
understand what is node-to-node communication in the sense you put it
here. I guess, IP is all about node-to-node communication.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Aug 2004 11:04:09 +0300 (EEST)

> document is kept narrow instead of over widening it. 

It doesn't seem useful to argue this point, so I'll just note that
I'll disagree with this approach because I don't think the
requirements actually are all that different.  The biggest difference
comes from the no-NAT assumption and the rest should be about the
same.

> stating that if something is not required it should be explicitly

It's up to the requirements of the scenarios to decide that :-).

The document could for example list examples of mechanisms/protocols
which do not need to be supported, or require that all should be
supported.  It depends on the scenario and conceived application
usage, both now and in future.  The key point in my comment is that it
needs to be very clearly stated if it's OK that certain v6 mechanisms
or protocols (such as DHCPv6, multicast, SEND, etc.) do not need to
work.

> If the terminal has to keep the tunnel alive, would it mean that it
> has to wake up the radio periodically (even when it would not need
> it otherwise) send a packet over the radio and possibly wait for
> answer. This means that it cannot be in a "dormant" mode all the
> time it's idle. This consumes battery quite a bit. In addition, it
> reserves radio resources for the sending of the keep-alive
> unnecessarily.

You mention good points and these should probably go in the draft in 
some form, as clarifying material.

(I certainly can't think of any protocol on the table which would 
*require* such keep-alives when there are no NATs to cross, but it's 
still good to have that goal specified.)

> here. I guess, IP is all about node-to-node communication.

I was using "node-to-node" communication as a shorthand for something
like "node-to-node communication inside the direct tunneling range",
i.e., local communication between nodes which could be directly
tunneled if the protocol supported it.

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Tue, 24 Aug 2004 15:04:58 +0300

> comes from the no-NAT assumption and the rest should be about the

I hope we will be able to compare the two finished set of requirements
very soon! ;)

> or protocols (such as DHCPv6, multicast, SEND, etc.) do not need to

Fair enough. Thus, if something does not need to work it has to be
documented. I guess, I agree with that.

> some form, as clarifying material.

I guess, Karen can see if there is a place in the document where this
can be documented.

> tunneled if the protocol supported it.

Ok. 

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34