Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt

[Pekka Savola <pekkas@netcore.fi>]

in-line,

On Thu, 21 Oct 2004, JORDI PALET MARTINEZ wrote:
> > A couple of comments on
> > draft-palet-v6ops-solution-tun-auto-disc-00.txt.  In short, this seems
> > like a start in narrowing down the list of methods given in
> > draft-palet-v6ops-tun-auto-disc-01.txt, but there are two problems
> > with this: 1) IMHO it isn't yet sufficiently far narrowed down ;-),
> 
> Our view is that if we want a resilience solution, we need some
> complementarily between DNS and anycast. It can be done just with DNS, but
> then it will work only within the ISP.
> 
> In our opinion we need a solution that works also outside the "customer"
> ISP.

There are a lot of nuances to 'working outside the "customer" ISP', 
for example:

Does the solution have to support complete 3rd parties, such as 
anycasting 6to4 relays now? (Remember that 6to4 relays are stateless, 
while the tunnel servers typically aren't, and this would cause 
additional implications on the mechanisms.)

Does the solution have to support those customers which momentarily 
roam outside of their ISP's access network?  [E.g., as solution based 
on DNS records would probably still be at least partially applicable 
here]

I'm concerned that because there is significantly smaller amount of
incentive, and more technical challenges, for ISPs to deploy an
inter-domain anycast solution for tunnel servers, so that it would not
be actually usable for discovery.

> > and 2)  the draft doesn't sufficiently describe the
> > mechanism/protocol/implementation requirements, and how those
> > interoperate with whatever the ISPs would deploy.
> 
> I'm not sure what do you mean here, but providing more details about DNS SRV
> RR and anycast seems to us out of the scope of this document. There are no
> _new_ requirements for the ISP, neither the client, because we are using
> existing mechanism (DNS and anycast).

No, I didn't mean that, but rather what mechanisms must be implemented 
in the mechanism or the host stack.  I'll try to explain below.

> > substantial
> > -----------
> > 
> > 1) the most fundamental issue I see with this draft builds on text in
> > section 4 about what is the mandatory-to-implement mechanism and what is
> > not.  That's important.
> > 
> > There are two perspectives here: 'mandatory to implement' in the specific
> > service (e.g., 6to4, TSP, Teredo, ISATAP, etc.), and 'mandatory to deploy'
> > in the ISP.
> > 
> > I think you've only focused on what the ISP should deploy.  You'll also need
> > to discuss what should be mandatory to implement in the
> > protocols/mechanisms, because this is where interop problems happen.
> 
> I think you're missing somehow the point. We are trying to do in such way
> that no modification is required for the existing transition mechanisms.
> Instead, the Operating System will require to replace the actual defaults
> for the TEPs (6to4, Teredo, etc.), which the name to be defined by IANA as
> part of the process of getting this document further.

Maybe I did not write clearly enough, without assumptions.

Whether or not this discovery process is done in the host stack, or 
the transition mechanism, is relatively irrelevant.

However, it is VERY MUCH relevant to this draft WHAT must be 
implemented in the host stack or the mechanism to make these work.

For example, if the host would just implement DNS lookups and the ISP 
just anycast, discovery process should fail.

So, when there are multiple mechanisms, one must specify what is the 
mandatory-to-implement part of them, and how different combinations of 
support in the stack/mechanism interoperate with different 
combinations of support in the ISP.

> > For example, if we just specified DNS lookup in a certain way, the ISP would
> > only have one way to deploy it and the mechanism one way to implement it,
> > and interoperability would be guaranteed.
> > 
> > "Less is more" ;-).  The current draft is IMHO not a clear solution.  It's a
> > "kitchen sink" description of best solutions, which may or may not work
> > together, and it may or may not be possible to get a well-interoperable
> > mechanism out of it.  I'd try to narrow down the number of different
> > discovery mechanisms used as much as possible.
> 
> We are using a single name for each protocol, so whatever is implemented in
> the ISP, will work for the client. I think this provides complete
> interoperability !

Yes, but you also specify the inter-domain anycast in addition to DNS 
lookups using SRV or A records.

Which ones must be supported in the client?  Which ones in the ISP?  
There are probably half a dozen non-interoperable combinations here.

Maybe your implicit assumption is that the client supports all of 
them: interdomain anycast, DNS with SRV, and DNS with A records, and 
maybe even DHCP to the boot -- and tries them in some particular 
order, and then it would just depend on what the ISP supports.

I don't have that assumption.  On the contrary, I think there must be 
a minimal set of approaches so that 1) very little is required to 
implement & deploy, and 2) there are as few interop problems as 
possible.

> > 2. Section 5.4 seems to be proposing using dual-faced DNS towards the
> > Internet vs own customers to control the visibility of the TEP addresses in
> > the DNS.  This seems completely wrong direction to take, because the
> > addresses will still be available even if they are not made available in the
> > public DNS.
> > 
> > The last paragraph says it all: it would be much better to forget about
> > dual-faced DNS completely in this context, and just perform filtering for
> > the service.  It offers complete solution to the "theft-of-service"
> > problems, and is easier and more correct way to deploy to boot.
> > 
> > So, please remove dual-faced DNS, unless there are some very strong unstated
> > assumptions what benefits it gives instead of just filtering (and state
> > them).
> 
> Our intend here is to offer two options:
> 1) No service at all outside the ISP (then filtering will make it)
> 2) An ISP that offers services (some, may be not the same) to users outside
> its own network. I think this is a possibility and we must support it in a
> clear way, in case somebody want to make use of it.

I can understand these options, but AFAIK dual-faced DNS does not
offer any better means to achieve 2), while being a lot worse.  Sure,
you can hide the tunnel endpoint (so that it can only be looked up in
the local net) and still keep it operational if you move away from the
network, but that allows a lot of abuse (such as local customers
telling their friends outside the IP address to use for their
tunnels).  Doing dual-faced DNS here would be security by obscurity
and that would not be good.

The only practical solution to the 3rd party case appears to be some 
form of registered mode, i.e., the tunnel endpoint being accessible to 
anyone, but only allowing certain registered users.

> > 3. In section 7, you mention alternative DHCP-based solution.  Because the
> > people not familiar with the tun-auto-disc background will first ask "why
> > not just use DHCPv4 and forget about everything else?", this section
> > probably needs to include much better justification (to be gathered from
> > the tun-auto-disc document, for example) why it's not the main proposal.
> 
> We wanted to avoid duplicating text from the requirements document ;-)

Worthy goal, but something DHCP proponents will jump on :-)

> > semi-substantial
> > ----------------
> > 
> >  On the other hand, shared anycast is also a very useful approach
> >  since it can globally identify a specific service (TEP or transition
> >  mechanism).
> > 
> > ==> I think you're assuming that anycast (shared-unicast) would be allocated
> > an interdomain range, because otherwise it can't be globally identified.
> > This doesn't need to be the case.
> 
> Our intend is to use the same prefix as for 6to4, for all the mechanisms (so
> we can allocate for example up to 254 new mechanisms, more than enough).

Uhh, I didn't quite understand: did you mean 192.88.99.2 for X, .3 for 
Y, .4 for Z, or "similar prefix as for 6to4", like 192.88.100.0/24 for 
X, .101.0/24 for Y, etc.

The former would definitely not work.

> > Also, did you find a source where "_ipv4" protocol comes from?  Is there an
> > example of this being used somewhere, or did you just make it up? :-)
> 
> In the SRV RR description is not indicated that ipv4 could be used, but is
> also not explicitly excluded, so should be an option. In fact, if the
> mechanism is used for autodiscovering IPv6 TEPs (when you want to tunnel
> 4in6, for example), it will be possible to use ipv6.
> 
> Actually, anyway, all them are possible examples, and in the case of TSP, it
> could be also _udp, _ipv4, _ipv6, etc.

OK, it seems that the SRV spec does not allocate a namespace for 
"protocol values" such as _tcp, so if something else than _udp or _tcp 
are used, they just need to be made up in such a manner that they 
don't conflict.

> >  To do that, the ISP's domain name is essential for prefixing the DNS
> >  search path, so the client (or rather the operating system) firstly
> >  learns the domain name of the ISP.  There are several ways to do it,
> >  but in general it will be learned by making NS RR queries to the DNS.
> > 
> > ==> You have assumptions in the last sentence, that the user looks up the IP
> > address and its corresponding NS records to get the domain name.  That's
> > certainly one approach.  But as currently deployed, folks just depend on the
> > DNS search path.  So, I think the last sentence needs to be expanded or
> > removed.
> 
> We are not referring to the IP address, but to the search path, as you say,
> so ?

If you have the search path, you don't need to make a NS RR query.  
NS RR query would only be needed if you wanted to look up the
responsible party for your IP address.

I couldn't figure out why you mentioned 'NS RR' there, so I made some 
conclusions.  I think the above is clarified if you remove or reword 
the text around NS RRs.

> > the client (rather the operating system)
> >  makes a DNS query [6][7] for QNAME=teredo_srv.ispname.com, QCLASS=IN,
> >  and QTYPE=A or QTYPE=CNAME.
> > 
> > ==> which QTYPE is it?  Are you saying the implementations need to query
> > both?  That's not good.  Note that if you do a QTYPE=A query, that should
> > also match CNAME and give the A record in the answer section, so there is no
> > need to query CNAME explicitly.  Try e.g. 'dig aaaa ftp.ipv6.funet.fi'.
> 
> No, just query one of both, the one the OS prefers ;-)

Uhh, you need to specify better what to do so that it can be done in
an interoperable manner.  Or if you specify you have to query both,
that's OK too, but causes significant issues because it takes 
additional packets and additional latency.

> > editorial
> > ---------
> > 
> >  4.  It is topologically correct: Provides the nearest TEP to the user
> >      in terms of hops.
> > 
> > ==> for the sake of clarify, please expand 'hops'.
> 
> IPv4 hops if looking for an IPv4 TEP (to gain access to IPv6).

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