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

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 26 Nov 2008 00:25:55 -0600

Hi All,

I'd like to put the proposed changes out of LIS discovery to the list before I start on document surgery.  I've done a little investigation, and I think that the following approach is workable.  Let me know if you think otherwise.

This email regards the reverse DNS components in the current document.  I'm sending another email on LIS authentication.

The major change is the removal of the reverse-DNS component.  That aspect of the document used a few too many assumptions; keeping those aspects as is doesn't work, and attempting to constrain the solution properly would only delay publication.  This basically equates to the removal of Section 4 of the current document, but it would also include major excisions in Sections 5 and 6.

I'd prefer to leave the U-NAPTR registration intact.  The document will not include a means of acquiring the domain name that is the input to DDDS.  I considered retaining the use of DHCP option 15, but a re-reading of RFC 2132 indicates that the intent of this is as a DNS search suffix.  To re-purpose the option would be inadvisable, even if this might work; the document will no longer contain funny heuristics.  

The document will state that the means by which a domain is acquired is out of scope (with a MAY on static configuration), but that the domain MUST be provided expressly for the purposes of LIS discovery.

The document will also provide stronger recommendations that limit how static configuration can be used:

 - static configuration must be a last resort - automatic methods are preferred because they are less susceptible to errors when a device moves

 - static configuration must be provided expressly for the purpose of LIS discovery - to take a URI (or domain name) from a web site, off the side of a bus is not appropriate.

If you have comments, reservations or suggestions, please post to the list before the end of next week (Dec 5).  I'd like to ensure that I'm not in crazy-person-land before I start ripping things up.

Cheers,
Martin

------------------------------------------------------------------------------------------------
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: Wed, 26 Nov 2008 20:11:34 -0500

> I considered retaining the use of DHCP option 15, but
> a re-reading of RFC 2132 indicates that the intent of this is as a
> DNS search suffix.  To re-purpose the option would be inadvisable,
> even if this might work; the document will no longer contain funny
> heuristics.

I'm all for removing funny heuristics, but I'm not sure we need to 
remove the use of option 15 altogether.  After all, RFC 2132 (S3.14) 
does say that option is "the preferred way to retrieve the domain name". 
   (BTW, what is the DHCPv6 analogue for this option?)  It might even be 
OK to allow fall-back to the FQDN option.

In either case, what's important here is that following chain works:
1. --DHCP--> Domain name
2. Domain name --DNS--> LIS URI
3. LIS URI --HELD--> Location
This requires coupling between the DHCP server and the DNS (there MUST 
be NAPTR records provisioned for any domains that show up in DHCP) and 
between the DHCP server, the DNS, and the LIS (the LIS referenced in a 
NAPTR record MUST be able to locate any hosts that receive the domain of 
the NAPTR in a DHCP option).  There should be text in Section 6 to 
explain these linkages.

In any case, we should get advice from the DHC WG on whether it's 
appropriate to use these options in this way.  I think the proposed 
changes (removing funny heuristics and clarifying dependencies) will 
address the DNS-based concerns that Peter raised.

> The document will state that the means by which a domain is acquired
> is out of scope (with a MAY on static configuration), but that the
> domain MUST be provided expressly for the purposes of LIS discovery.
> 
> 
> - static configuration must be a last resort - automatic methods are
> preferred because they are less susceptible to errors when a device
> moves
> - static configuration must be provided expressly for the purpose of
> LIS discovery - to take a URI (or domain name) from a web site, off
> the side of a bus is not appropriate.

I don't really see the point of this text.  Static configuration is 
always an option; the whole point of a discovery document is to define 
how to avoid static configuration.

In any case, I don't really see how recommendations of this character 
are really useful in a specification.  They're really only relevant to 
end users, who aren't the intended audience for this document anyway.

--Richard (participant hat on)

---

From: [email-masked]
Date: Thu, 27 Nov 2008 09:42:40 +0000

> explain these linkages.> 

I'm against this, for similar reasons to my objections to the PTR record 
version.

If a small enterprise wants to use their own domain name internally and 
distribute that setting using DHCP Option 15[*] they MUST be able to do so 
without being required to put appropriate NAPTR records and/or run a local 
LIS.

In any event, most DHCP servers on home gateways either:

1. don't have an Option 15 setting
2. default to blank
 or
3. default to 'belkin.' or similar

Ray

[*] coincidentally, this option was my first contribution to an RFC, c. 
1992!

---

From: Richard Barnes <[email-masked]>
Date: Thu, 27 Nov 2008 09:28:10 -0500

Hi Ray,

> without being required to put appropriate NAPTR records and/or run a local 

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

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.

> 3. default to 'belkin.' or similar

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.

--Richard

---

From: [email-masked]
Date: Thu, 27 Nov 2008 16:08:23 +0000

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

> 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

> 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

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: "Stark, Barbara" <[email-masked]>
Date: Sun, 30 Nov 2008 21:43:54 -0500

I haven't been following this closely, and I think I should pay more
attention. One of the chief drivers for HELD was to be able to use it
without upgrading the home router (e.g., a soft client or SIP phone
somewhere inside a home network). We must have a mechanism for LIS
discovery that allows for discovery across this dumb router, which has
its own DHCP server (that won't be doing the new DHCP option), and which
establishes its own domain (and doesn't pass on the domain of the WAN).

Do we have a mechanism for LIS discovery that works across an old home
router and is still in the proposed overhaul of the draft?
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomson, Martin
Sent: Wednesday, November 26, 2008 1:26 AM
To: [email-masked]
Subject: [Geopriv] Proposal for LIS discovery (DNS)

Hi All,

I'd like to put the proposed changes out of LIS discovery to the list
before I start on document surgery.  I've done a little investigation,
and I think that the following approach is workable.  Let me know if you
think otherwise.

This email regards the reverse DNS components in the current document.
I'm sending another email on LIS authentication.

The major change is the removal of the reverse-DNS component.  That
aspect of the document used a few too many assumptions; keeping those
aspects as is doesn't work, and attempting to constrain the solution
properly would only delay publication.  This basically equates to the
removal of Section 4 of the current document, but it would also include
major excisions in Sections 5 and 6.

I'd prefer to leave the U-NAPTR registration intact.  The document will
not include a means of acquiring the domain name that is the input to
DDDS.  I considered retaining the use of DHCP option 15, but a
re-reading of RFC 2132 indicates that the intent of this is as a DNS
search suffix.  To re-purpose the option would be inadvisable, even if
this might work; the document will no longer contain funny heuristics.  

The document will state that the means by which a domain is acquired is
out of scope (with a MAY on static configuration), but that the domain
MUST be provided expressly for the purposes of LIS discovery.

The document will also provide stronger recommendations that limit how
static configuration can be used:

 - static configuration must be provided expressly for the purpose of
LIS discovery - to take a URI (or domain name) from a web site, off the
side of a bus is not appropriate.

If you have comments, reservations or suggestions, please post to the
list before the end of next week (Dec 5).  I'd like to ensure that I'm
not in crazy-person-land before I start ripping things up.

Cheers,
Martin

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 30 Nov 2008 22:42:31 -0600

Hi Barbara,

The proposal is to produce an incomplete solution.  There's no great reason for this aside from the fact that it lets us get HELD finished sooner.

The DNS components of discovery are controversial.  It is my belief that with a properly documented set of constraints they will work.  The problem is that this takes time.  This is made worse by those people who keep coming up with flavour-of-the-month discovery methods.

The view was that to factor that time into the critical path on HELD wouldn't work.  As long as the WG recognises that the solution is incomplete, then all this wont add any more delay than otherwise, with the added benefit of getting HELD out sooner.

Of course, that's all conditional on the outcome of charter discussions.  But I'll have my say on that too.

Cheers,
Martin

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Monday, 1 December 2008 1:44 PM
> To: Thomson, Martin; [email-masked]
> Subject: RE: [Geopriv] Proposal for LIS discovery (DNS)
>