Subject: zeroconf draft

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Thu, 19 Aug 2004 21:20:20 +0200

Hi,

Enclosed please find a first draft detailing the goals of zero configuration tunnelling as
seen by the authors.

The draft has been submitted to the IDs, but in order to meet the 2 weeks deadline set up
at Thursdays v6ops session in San Diego I have taken the liberty to include the draft here.
I hope that's acceptable.

 <<draft-nielsen-v6ops-zeroconf-goals-00.txt>> 
BR, Karen

-----------------------------------------------------------
Karen Egede Nielsen, System Manager, Ericsson Telebit A/S
Phone:  + 45 89385100, Fax:  + 45 89385101
Phone Direct: + 45 89385313, Mobile:+ 45 25134336
[email-masked]
-----------------------------------------------------------

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 19 Aug 2004 17:39:46 -0400

Hi all,

The I-D is also available at http://www.v6ops.euro6ix.net/ietf/draft-nielsen-v6ops-zeroconf-goals-00.txt.

Comments and inputs to this work are very welcome !

Regards,
Jordi

----- Original Message ----- 
From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 19, 2004 3:20 PM
Subject: zeroconf draft

>  <<draft-nielsen-v6ops-zeroconf-goals-00.txt>> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 20 Aug 2004 13:43:17 +0300 (EEST)

> Enclosed please find a first draft detailing the goals of zero configuration tunnelling as

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

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sun, 22 Aug 2004 19:35:17 -0400

Hi Pekka,

My personal comments/question in-line.

Regards,
Jordi

---- Original Message ----
From: "Pekka Savola" <[email-masked]>
To: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 20, 2004 6:43 AM
Subject: Re: zeroconf draft

>> Enclosed please find a first draft detailing the goals of zero
>> configuration tunnelling as seen by the authors.
> 
> Thanks!
> 
>  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. 

I think it will be possible, and indeed very useful, to have in some parts of the text two sections, one considering the 3GPP case (applicable also to others like dial-up, ISDN, etc., which have similar "problems" as low bandwidth/high cost), and another one for the "broadband" case. Do you agree this could be useful if perfectly clarified across the text ?. At this way in a single document we can have requirements for two types of scenarios, which have a lot of common, but some small differences that could lead to a couple of slightly different solution variants, while I also agree that if we can have a single solution working in both scenarios, will be optimal (for example, detecting the scenario in order to provide some added-value features).

>   For example, is multicast envisaged as something that should be

Ok. We probably need to add some text to clarify that.

>   better, but that's just semantics, not something we need to worry

Yes, but better if we start thinking now in something better. Suggestions ?

> more substantial

Yes ND/RA should work, so we need to concrete. We are referring more to other options like having a prefix instead of a single address, supporting DNS with IPv6 transport, etc..

> advertisements or other indications of IPv6 connectivity are available
> over the native interface.
> 

Yes, agree, we aren't intending to say that the link should be monitored in case suddenly IPv6 native comes up.

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

Yes, the idea is to avoid unnecessary keep-alive, heartbeat or whatever traffic "link-up" signaling.

> 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

The idea is that the solution is stateless, so should not be a need for garbage collection. Anyway, this is part of the solution ... at the time being we prefer to not consider the solution for this, but try to make it as much "zero-configured" as possible, in both the client and server side. Do you think is a really unrealistic requirement ? May be we just need to step back and ask for some kind of signaling with low periodicity ? But I think if we look for a manual configured 6-in-4, it just works ... if the link/tunnel dies, the transmissions will time out, and the solution should find the way to reestablish the tunnel. The difference is that this solution should auto-configure the tunnel.

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

I'm not convinced that we can make a so simple protocol that at the same time provides node-to-node communication. In any case, I feel that in the scenarios which we are targeting, traffic go in any case to the ISP network, so what will be the advantage of trying to solve that ?

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

As said, we are trying to avoid any state in the server ... I guess to avoid this kind of "threat", we need something like:

"No specific threats to the tunnel server have been identified. Nevertheless this is considering that the tunnel server has been adequately provisioned in order to cope with all the maximum expected traffic in that network".

> 
> By proxy, would this call for adding a goal for being able to distribute
> the tunnel server load among multiple tunnel servers?

This is perfectly possible by means of an adequate auto-discovery of the TEP, which can provide the required load balancing among multiple tunnel servers.

> "Tunnel Client" as well if tunnel endpoint is meant to be a generic term?

We should clarify that.

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

Agree. I will say:
"A dual-stack server node with IPv6 connectivity (native or by means of a transition mechanisms) ..."

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

May be:
- The nodes of the network infrastructure can not protect the end-host by means of a default filtering of intra-site (i.e. internally sourced and destined) 6-in-4 packets.
- Being the tunnel service non-authenticated (not explicitly registered), the tunnel server may be used to reflect tunneled packets into the network, similarly to the 6to4-reflection attacks identified in ...
- The usage of zero-configuration tunneling may create threats to other proto-41 encapsulation-based mechanisms being used in the network.

> ==> I had hard time parsing the first lines of this loooong sentence

For an end-host using zero-configuration tunneling to be able to trust in the legitimacy of the traffic received from the tunnel server, should be sufficient that the tunnel server discovery mechanism is trustworthy.

> 10. Authors Contact Information

ok.

> ==> splitting the refs to normative/informative might not hurt..

Right.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Aug 2004 08:47:02 +0200

Can the authors clarify in section 4.1 whether IPv4 multicast is
assumed to be enabled or disabled? It will make a big difference
to the possible solutions.

Thanks
     Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 23 Aug 2004 12:43:06 +0300 (EEST)

On Sun, 22 Aug 2004, JORDI PALET MARTINEZ wrote:
> I think it will be possible, and indeed very useful, to have in some
> parts of the text two sections, one considering the 3GPP case
> (applicable also to others like dial-up, ISDN, etc., which have
> similar "problems" as low bandwidth/high cost), and another one for
> the "broadband" case. Do you agree this could be useful if perfectly
> clarified across the text?

I'm slightly concerned whether this generalization of low-end 
connectivity (3GPP, dial-up, ISDN, etc.) have exactly the same 
requirements, so I'm not sure how well they could be bundled in 
together.

> At this way in a single document we can
> have requirements for two types of scenarios, which have a lot of
> common, but some small differences that could lead to a couple of
> slightly different solution variants, while I also agree that if we
> can have a single solution working in both scenarios, will be
> optimal (for example, detecting the scenario in order to provide
> some added-value features).

As I pointed out, I think it would be very useful if this kind of
document either focused solely on one particular scenario, or
considered the related, similar scenarios (e.g., ISP broadband, maybe
narrowband as well, but that's probably pretty close to ISP broadband
as well).

I mean, If we look at the slightly different scenarios in isolation, 
we may be missing a big picture.  That's why covering the similar 
access-network tunneling scenarios from ISP/unmanaged space would seem 
to be beneficial.

> Yes, but better if we start thinking now in something better.

Not right out .. let's not delay the document for this, though.  We 
can tweak it a bit later when we have better consensus and idea where 
this is going.

> Yes ND/RA should work, so we need to concrete. We are referring more
> to other options like having a prefix instead of a single address,
> supporting DNS with IPv6 transport, etc..

My point is, is it acceptable for the solution to impose constraints
on IPv6 protocols and mechanisms used?  In the end, the tunnel is just
an IPv6 link -- typically you should have to run everything on top it,
independent of whether it's "native" or "tunnel" link... be that DNS
with v6, DHCPv6, etc. -- it shouldn't matter.

I think it should be clearer that normally everything works out of the
box, and the solution must clearly specify if it doesn't work
appropriately with some of the v6 protocols.  (E.g., ISATAP w/ DHCPv6
address/prefix assignment or multicast.)

Further, it might not hurt to be more explicit on which protocols need 
or need not be supported.

> The idea is that the solution is stateless, so should not be a need
> for garbage collection. Anyway, this is part of the solution ... at
> the time being we prefer to not consider the solution for this, but
> try to make it as much "zero-configured" as possible, in both the
> client and server side. 

These assumptions (except for the solution .) should probably 
translate to some kind of text in the doc..

> Do you think is a really unrealistic
> requirement ? May be we just need to step back and ask for some kind
> of signaling with low periodicity ? But I think if we look for a
> manual configured 6-in-4, it just works ... if the link/tunnel dies,
> the transmissions will time out, and the solution should find the
> way to reestablish the tunnel. The difference is that this solution
> should auto-configure the tunnel.

As noted, Neighbor Unreachability Detection must be run with manually
configured v6-in-v4 tunnels, which already results in that kind of
signalling, unless NUD has been explicitly disabled on the interface.

So, what I'd like to clarify is whether you already assume that NUD as 
well has been disabled (i.e., there is no unreachability detection 
process at all), whether you assume that NUD would be used but don't 
want to add anything more, or that running something would be OK as 
long as it's low-frequency and configurable (to be turned off, for 
example) by the user.

> I'm not convinced that we can make a so simple protocol that at the
> same time provides node-to-node communication. In any case, I feel
> that in the scenarios which we are targeting, traffic go in any case
> to the ISP network, so what will be the advantage of trying to solve
> that ?

I'm not sure if I understand your comment.  I wasn't arguing for
node-to-node communication :) -- I was just pointing out that the
mitigation strategy simply doesn't work, so the document should say
that direct tunneling issues cannot be mitigated (that way) because it
would break the protocol.  Either the protocol must not have direct
tunneling, or the risks must always be acceptable.

> As said, we are trying to avoid any state in the server ... I guess
> to avoid this kind of "threat", we need something like:
> 
> "No specific threats to the tunnel server have been identified.
> Nevertheless this is considering that the tunnel server has been
> adequately provisioned in order to cope with all the maximum
> expected traffic in that network".

There was also another point, not just state (which is probably
included in the text you propose): my concern is that if the server
cannot handle state for N (N might be e.g., 100,000) hosts (if the
solution is stateful), how different would it be for a stateless
solution?  I mean, the stateless server would probably crash just the
same when the actual traffic started flowing.  In other words, the 
servers need to be provisioned to handle both the state (if 
applicable) and the traffic.  The latter is probably a more difficult 
challenge, so I'm not quickly seeing why state as such would be a 
show-stopper.

> This is perfectly possible by means of an adequate auto-discovery of
> the TEP, which can provide the required load balancing among
> multiple tunnel servers.

Of couse, but it doesn't seem to be listed among the requirements.

[snip editorials -- I wasn't sure how much clearer the two unclear 
ones went, but hopefully someone else will take a look as well..]