Re: zeroconf draft

[Pekka Savola <pekkas@netcore.fi>]

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 assymptions 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 tunneling), 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.

  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?

  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?

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?

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

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

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

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?


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