[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: zeroconf draft
Pekka, Karen,
On Tue, 2004-08-24 at 08:50, ext Pekka Savola wrote:
> 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.
This, of course, has been a sticky point from the beginning. There seems
to be two schools of thought: One saying that assisted tunneling's
simple mode would fit the 3GPP scenarios. The other is saying that
assisted simple mode does not fit the requirements of 3GPP. Thus, an
additional document was decided to be created to see if the requirements
are the same instead of artificially putting the two possibly
distinguished set of requirements into the same document.
I believe if the scope is kept well and not bloating the document with
non related requirements we can do the analysis of the two set of
requirements and see of the two sets are equal.
So, from my perspective I think it is important that the scope of the
document is kept narrow instead of over widening it.
>
> > 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.
Are you saying that everything that is supported by native v6 (e.g.
multicast) must be supported by the tunneling mechanism, or are you
stating that if something is not required it should be explicitly
documented?
>
> > > ==> 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.
The problems of the keep-alive mechanisms over wireless links are
battery consumption, radio resource reservation, and depending on
operator's business model cost. The first two I would personally
consider as the main problems.
If the terminal has to keep the tunnel alive, would it mean that it has
to wake up the radio periodically (even when it would not need it
otherwise) send a packet over the radio and possibly wait for answer.
This means that it cannot be in a "dormant" mode all the time it's idle.
This consumes battery quite a bit. In addition, it reserves radio
resources for the sending of the keep-alive unnecessarily.
>
> > > 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.
Maybe I'll find the definition in the other thread, but I don't really
understand what is node-to-node communication in the sense you put it
here. I guess, IP is all about node-to-node communication.
Cheers,
Jonne.
>
> > > 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.)
--
Jonne Soininen
Nokia
Tel: +358 40 527 46 34
E-mail: jonne.soininen@nokia.com