Re: [Geopriv] LIS discovery implementation thoughts

["Thomson, Martin" <[e-mail]>]

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