Re: zeroconf draft

["JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>]

Hi Pekka,

My personal comments/question in-line.

Regards,
Jordi

---- Original Message ----
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
Cc: <v6ops@ops.ietf.org>
Sent: Friday, August 20, 2004 6:43 AM
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 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).

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

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

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

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

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

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

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

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

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

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

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

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.

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

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 ?

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

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.

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

We should clarify that.

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

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

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

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.


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

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
> 
> ==> "Authors' Addresses"

ok.

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

Right.




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