Subject: [Geopriv] Comments on draft-ietf-geopriv-lis-discovery-04

From: Cullen Jennings <[email-masked]>
Date: Tue, 4 Nov 2008 15:49:42 -0700

The usage of UPnP seems to be at best half baked from security point  
of view and I don't think it will work. There are problem with people  
pretending to be the UPnP server of the NAT when they are not and  
problems of UPnP only retrying the Ip of the innermost NAT when you  
have nested NATs. I think this either needs to be fully specified or  
removed - my preference, given the urgency to finish this, would be to  
remove UPnP and related things or at least discuss the issues.

The statement
    If the discovery process fails, user interaction is NOT  
RECOMMENDED. The discovery process is not easily diagnosed by a user.
Seems very concerning. I realize what you are trying to get at but if  
E911 calls are going to fail, and my phone knows that, I think my  
phone should tell me that.

I'm just wondering about the reverse DNS lookup. I imagine this has  
been discussed before but the draft does not mention it. Say I get a  
static IP from ISP for my home connection because I do gaming and I  
also get a DNS name for my web server I run at home. My ISP should put  
in a PTR record for that that points at my domain. Now I would need to  
put in DNS entries to point back out my ISP LIS. This is less than  
idea. I'm not arguing we should remove the reverse IP discovery but we  
should at least consider this.

Trivial thing ... The example in section 3 might better illustrate  
things if the node a and b were at example.com, but the outsource was  
at example.net and the https URL pointed at example.org just to show  
the domains don't have to be related.

All of this sent with my individual contributor hat on
Cullen
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 4 Nov 2008 17:07:51 -0600

Hi Cullen,

Thanks for the comments.

> remove UPnP and related things or at least discuss the issues.

UPnP is not a mandatory part of the procedure.  If there was something that gave you a different impression, please let me know and I'll remove it.  Section 4.2.2 discusses alternative methods for discovery and provides guidance on when those alternative methods are appropriate.  My view is that this section is helpful from an informative perspective.  If others are of the opinion that this does more harm (c.f. above comment) than good, then it's relatively easy to drop.

> phone should tell me that.

The intent was not to prevent users from knowing about failures, but from asking stupid questions like "where is your LIS?", or "DHCP didn't work, and I can't seem to find a STUN server, help!".  On consideration though, removing the note might be a better trade-off.

> should at least consider this.

There is a concern where individual domains are granted by the access network provider.  In that case, each domain that is indicated by the reverse DNS records needs a NAPTR record.  I will add a small note/example to the next revision that highlights this case.

Alternatively, the ISP doesn't provide the PTR record to your private domain.  They continue to use their own domain for reverse DNS.  This would be the same if you used dyndns.org and similar services to get your private domain.  There are very few cases where getting the PTR to your private domain actually helps.
 
> the domains don't have to be related.

Thanks Cullen.  Will do.

> All of this sent with my individual contributor hat on

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