[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: zeroconf draft
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:pekkas@netcore.fi]
> Sent: Friday, August 20, 2004 12:43 PM
> To: Karen E. Nielsen (AH/TED)
> Cc: v6ops@ops.ietf.org
> 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
>