Re: zeroconf draft

[Pekka Savola <pekkas@netcore.fi>]

On Sun, 22 Aug 2004, JORDI PALET MARTINEZ wrote:
> >  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?

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings