Subject: Re: [Geopriv] Proposal for LIS discovery (DNS)

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2008 16:35:41 -0500

Ray,

I'm willing to grant that the local gateway shouldn't pass through 
option 15.  My mistake.

However, I still don't understand why it doesn't make sense for a host 
to use option 12 or option 15 to look for a LIS.  Those domains are 
supposed to label the host (12) or local network (15), so wouldn't it 
make sense to use a query for those names to ask for information on 
those entities?

Perhaps there's a disconnect here because the local network (in the 
sense of the entity that's providing DHC) isn't always the network that 
can sensibly provide a LIS.  We've talked about this being the case when 
the layer-3 provider needs to talk (LIS-to-LIS) with a layer-2 provider. 
  But it can also happen when the local network delegates positioning to 
an upstream provider, as when a home LAN (with its own DHCP) relies on a 
broadband provider for positioning.

Even in these cases, I think it still makes sense for a host to use the 
name of the local network to discover the local (possibly delegated) 
LIS.  It is, however, the responsibility of the local network to enable 
this delegation by redirecting clients appropriately.

There are several ways to effect this delegation, many of which don't 
meet Barbara's "unmodified gateway/CPE" requirement.  One option that 
seems appealing for me is for the gateway to do LIS discovery upstream, 
and use the result to act to answer NAPTR queries for its own domain 
(acting as a DNS proxy).  It's harder when the gateway is completely 
oblivious, especially given that lots of gateway manufacturers set all 
their devices to return the same value in option 15.  In this case, the 
responsibility for delegation is on the gateway vendor to answer NAPTR 
queries to the appropriate domain(s), but they could still use those 
answers to delegate to the appropriate upstream networks (and here those 
NAPTR records in in-addr.arpa might actually be helpful!).

--Richard

[email-masked] wrote:
>> I didn't mean to say "if you use Option 15, then you MUST provision 
>> NAPTR records".  The MUSTs only apply if the access network wants to 
>> enable DNS-based discovery (and maybe they're SHOULDs).
> 
> That's sort of the point.  There is _no_ guaranteed linkage between the 
> access network and the domain names used by the end-user within the LAN. 
> DNS based discovery based on the RDATA of a PTR record could never work 
> reliably.
> 
> Putting NAPTR records directly into in-addr.arpa (looked up based on a 
> STUN/UPnP discovered WAN address) might work better, although there'd 
> still be issues where the customer has a routed CIDR block and the ISP has 
> delegated some part of in-addr.arpa directly to the end-user.
>  
>> Were you thinking about a network that supports DNS-based discovery, but 
> 
>> doesn't use DHCP to distribute the domain name to clients? (I imagine 
>> this is one way you could hack around the "belkin" issue below.)  You're 
> 
>> right that argues for the MUSTs to be SHOULDs (at least the first one).
>>
>> But even in that case, the network operator should be aware that clients 
> 
>> on their network that don't have the static domain configured are still 
>> going to try the domain they get from option 15 first.
> 
> I strongly believe option 15 should not be used.
> 
> 1.  It's an abuse of the option
> 2.  It relies on the incorrect assumption above
> 
>> One other thing that would be helpful to add (maybe in S6) is some 
>> guidance for middle-box makers on how to do better than this.  If the 
>> gateway is provisioned over PPP, maybe you can't do much better, but if 
>> the gateway is getting option 15 on its upstream/public face, then it 
>> MUST pass it through to option 15 on the downstream/private face.
> 
> I've already written a draft about middle-box behaviour 
> (draft-bellis-dnsext-dnsproxy-00) which will be available as 
> draft-ietf-dnsext-proxy-00 any day now.
> 
> Middle boxes absolutely must NOT copy option 15 from WAN DHCP into LAN 
> DHCP.  Option 15 is intended for site-network configuration, not access 
> provider configuration.
> 
> Ray
> 
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Dec 2008 16:22:51 -0600

Hi Richard,

I know this is probably less motivated than I'm going to imply, but I have to pick on you for this:

> Barbara's "unmodified gateway/CPE" requirement.

If we persist on labelling the use case as belonging to Barbara, then we are purposefully disregarding its seriousness.  I understand how this is requirement poses a very difficult problem, but all this does is give the impression that you are reluctant to solve the problem.

Barbara just happens to be the one who raised the problem.  We could pretend that this is limited to the few that access the Internet through her employer's network, but that doesn't work.  

I personally have such a device.  I can't see a manufacturer adding features to a device that they no longer sell.  And I've got better things to do with my money than replacing working equipment.

I'm of the opinion that we can't rely on option 15 to solve the hard problem.  If you could rely on option 15, it would be reasonable to say that the LIS URI option could work.  If we are talking about modified routers, this is the "right" way to solve the problem.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Friday, 12 December 2008 8:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Geopriv] Proposal for LIS discovery (DNS)
> 
> Ray,
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Thu, 11 Dec 2008 18:03:07 -0500

Martin,

I'm sorry if that sounded derogatory; it certainly wasn't meant to be. 
I definitely agree that it's an important use case to support -- my DSL 
modem/gateway is as dumb as all the rest (and it's on a network that 
Barbara has nothing to do with (AFAIK)).

I guess part of what I'm saying here is that in this use case, using 
option 15 gives you something of a bootstrap to get to the right place: 
It gives clients a first point of contact that might know something 
about what's going on.

For example: My home gateway gives out a subdomain of its manufacturer's 
domain in option 15, which means that the manufacturer would be the one 
getting my LIS discovery queries.  To answer those queries, the vendor 
still needs to figure out which LIS is responsible for my IP address, 
but he's probably in a much better position to do that than I am (e.g., 
he probably already sees my public IP address).

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Dec 2008 17:44:19 -0600

Derogatory: not really :)  It's more of a sense that I get (in general) that because the problem is hard, it should be avoided.  Maybe I've become overly sensitive to this after working on the problem for so long.

As for your suggestion, I can't see a vendor being happy about having to run a LIS.  If the only benefit is that they can see a public IP, I'd suggest that we have better tools for that.  The only change I see coming from this is that vendors will stop providing option 15.

Cheers,
Martin

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Friday, 12 December 2008 10:03 AM
> To: Thomson, Martin
> Cc: [email-masked]; [email-masked]
> > If we persist on labelling the use case as belonging to Barbara, then
> we are purposefully disregarding its seriousness.  I understand how
> this is requirement poses a very difficult problem, but all this does
> is give the impression that you are reluctant to solve the problem.
> >
> > Barbara just happens to be the one who raised the problem.  We could
> pretend that this is limited to the few that access the Internet
> through her employer's network, but that doesn't work.
> >
> > I personally have such a device.  I can't see a manufacturer adding
> features to a device that they no longer sell.  And I've got better
> things to do with my money than replacing working equipment.
> >
> > I'm of the opinion that we can't rely on option 15 to solve the hard
> problem.  If you could rely on option 15, it would be reasonable to say
> that the LIS URI option could work.  If we are talking about modified
> routers, this is the "right" way to solve the problem.
> >
> > Cheers,
> > Martin
> >
> >>   But it can also happen when the local network delegates
> positioning
> >> to
> >> an upstream provider, as when a home LAN (with its own DHCP) relies
> on
> >> a
> >>> Putting NAPTR records directly into in-addr.arpa (looked up based
> on
> >> a
> >>>> Were you thinking about a network that supports DNS-based
> discovery,
> >> but
> >>>> gateway is provisioned over PPP, maybe you can't do much better,
> but
> >> if

---

From: [email-masked]
Date: Fri, 12 Dec 2008 10:22:49 +0000

> I'm willing to grant that the local gateway shouldn't pass through 

OK :)
 
> make sense to use a query for those names to ask for information on 

If they were universally supported, then perhaps.  The fact is, though, 
they're not.  Gateways currently have limited support for option 15, and 
generally non-existent support for option 12.

> broadband provider for positioning.

It's not that the local network "isn't always" the network operating the 
LIS.  For consumers and small businesses it will be the case that the 
local network will _almost never_ be the network operating the LIS.  The 
LIS-to-LIS stuff for L3 -> L2 is a red herring in this context.

Also, it's not just that disconnect between the local network and the LIS, 
it's the disconnect between domain names and local network and/or provider 
network infrastructure.

For example, I have a /28 network at home, and my PTR records have my own 
domain name on them.  That's a relatively common configuration for small 
businesses.

How does the current draft support me if:

1.  I don't want to replace my gateway

    -> DHCP discovery can't be used

2.  I've got my own domain name on the PTR records for my public IPs

    -> so maybe DNS discovery can be used _if_ I'm prepared to
       put NAPTRs for my ISP's LIS in my zone in the public DNS

3.  But I've got multiple offices using different ISPs, but all using
    the same domain name

    -> so I can't use DNS after all

Alternatively:

1.  determine my public IP (STUN / UPnP / etc)
2.  look up a LIS NAPTR record in in-addr.arpa for that IP
3.  ...
4.  profit!

This should still work even if your provider uses carrier grade NAT or 
similar (such that each user doesn't get their own public IP) so long as 
the resulting LIS server has visibility of the end-user's pre-NATed IP 
address (or other identity, as per held-identity-extensions).

> this delegation by redirecting clients appropriately.

What element on the local network is supposed to achieve that redirection?

> (acting as a DNS proxy).

Dear god no!!

Please see my SSAC report (http://public.icann.org/files/ssac/sac035.pdf) 
to get some idea of how broken gateway DNS proxies already are, and also 
<draft-ietf-dnsext-dnsproxy> for my proposals on how to fix that.  Putting 
_more_ DNS hackery in the gateway is NOT (imho) the answer.

> It's harder when the gateway is completely 

> NAPTR records in in-addr.arpa might actually be helpful!).

The idea that I might have to rely on my gateway vendor to provide ongoing 
support for LIS discovery fills me with horror.

cheers,

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv