Re: [Geopriv] LIS discovery implementation thoughts

["Richard L. Barnes" <[e-mail]>]

I'm assuming you mean the authentication against the input to the U-NAPTR process?  

The way we have things structured, we have separate modules that communicate via pub/sub:

measurements  ---+
                 +--> held --> zeus-locator [== application API]
lis-discovery ---+ 

(DHCP location is parallel to the HELD module, and also feeds the application API.)

The messages that the the lis-discovery module emits are of the form:
struct LisDiscoveryInfo {
    std::string lisUri;
    std::string domain;
}

So:

1. We could in principle do authentication against the input to U-NAPTR -- if it's supported by the underlying HTTP library.  Right now, we're using libcurl, which does not support changes to the name that it authenticates.

2. At the same time, it would be awkward for the lis-discovery module to do HELD requests required to "verify that the LIS is able to provide location information".  It's not impossible (there's actually a separate HeldRequest object (think like XMLHttpRequest) that could be used), but it would feel kind of like a circular dependency.

--Richard



On Jan 24, 2011, at 7:43 PM, Thomson, Martin wrote:

> What are your thoughts on the server authentication requirements?  Or is that another part of the validation that you aren't performing?
> 
> I have to commend the approach you are using.  I always hoped that this is how discovery would be implemented.
> 
> --Martin
> 
> On 2011-01-14 at 15:47:58, Richard L. Barnes wrote:
>> One additional note: Our client is not technically compliant with RFC
>> 5986, since it doesn't validate the URI with a HELD request:
>> "
>>   A Device that discovers a LIS URI MUST attempt to verify that the
>> LIS
>>   is able to provide location information.  For the HELD protocol, the
>>   Device verifies the URI by making a location request to the LIS.
>> "
>> 
>> --Richard
>> 
>> 
>> On Jan 13, 2011, at 11:45 PM, Richard L. Barnes wrote:
>> 
>>> Hey all,
>>> 
>>> Just wanted to share some impressions of the LIS discovery process,
>> including NAT traversal, based on our experience implementing this
>> function in the igtk project [1].  (Note: The techniques here haven't
>> yet been merged into the sourceforge version.)
>>> 
>>> The basic flow-chart in RFC 5986 is pretty easy to implement,
>> although it wasn't really clear what to do for step (3), "Check URI",
>> beyond verifying that it's a well-formed URI.  In pseudo-code, we ended
>> up with something like this:
>>> 
>>> foreach (NetworkInterface iface) {
>>>   DomainIterator it(iface);
>>>   while (it.hasNext()) {
>>>       string lisUri = performDdds(it.next());
>>> 	if (valid(lisUri)) { return lisUri; }
>>>   }
>>> }
>>> 
>>> Here the DomainIterator supplies the following domains, if they are
>> available:
>>> 1. Option 213 [NB: Not DHCPv6 capable]
>>> 2. Option 15
>>> 
>>> The DomainIterator construct also allows us to easily extend the
>> process to support NAT traversal.  If neither of the above options
>> works, the DomainIterator looks at the IP address for the interface,
>> and if it's private (any of the IANA reserved ranges [2]), then it does
>> a STUN request to find a public address.  Using either the interface
>> address or the STUN address, it then provides the following domains:
>>> 3. The reverse domain
>>> 4. The reverse domain with the first label dropped
>>> 5. The reverse domain with the first two labels dropped
>>> 
>>> The entire LIS discovery service, which listens for network interface
>> changes and emits alerts when it finds a new LIS URI, required 584
>> lines of C++.  A very basic STUN client was another 293.
>>> 
>>> So in a nutshell, extending a client from RFC 5986 to draft-thomson-
>> geopriv-res-gw-lis-discovery was pretty trivial, just a matter of
>> adding a few domains to the search list.  We hope to have the code
>> posted to the igtk site soon; if you're interested in an advance copy,
>> let me know and I can send you an interim snapshot.
>>> 
>>> --Richard
>>> 
>>> 
>>> [1] <http://igtk.sourceforge.net/>
>>> [2] <http://www.iana.org/assignments/ipv4-address-space/ipv4-address-
>> space.xml>
>>> _______________________________________________
>>> Geopriv mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/geopriv
>> 
>> _______________________________________________
>> Geopriv mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/geopriv
> 
>