RE: zeroconf draft

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 23 Aug 2004, Karen E. Nielsen (AH/TED) wrote:
> 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.)

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

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

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

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

Right.
 
> I believe the second is a valid point for all nodes processing 
> 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>).
> 
> Load balancing could be good, whether its really required by this 
> miminal function, I am not sure.

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings