RE: [Geopriv] HELD bindings and relevance to identity extensions

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

 

With respect to the following point:

 

 

[JW] Suppose HELD is bound to a transport other than HTTP, such as in
http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-01, how are
the parameters simply added to the URI? Does it even make sense to do
so? 

 

[ML] Hmm....HELD = HTTP enabled location discovery is bound to a
transport other than HTTP?

 

[ML] I realize Barbara's concern and offered an alternative, asking why
it doesn't solve her use case.  To state there are 'several' more adds
nothing to this thread. 

 

Very early in the piece, when the first HELD draft was submitted, we
were encouraged to specify alternative bindings for the protocol. It's
been observed a few times that the protocol name contains an epithet
that isn't strictly applicable any longer - but there was a body of
opinion that said keep the name for continuity and that's what has
happened. Nevertheless the wisdom of proposing other bindings has
certainly become evident to the authors since then.

 

In your basic device-LIS interaction, HTTP is good - it's easy to
implement and plays nicely in the considerable majority of networks.
Similarly, using it for dereferencing is good for the same reasons -
reaching a LIS behind an operator firewall is easy on the network
operator's IS policies if it comes in on HTTP. However, when it comes to
LIS-LIS traffic between elements within an operator environment or, in
particular, between operator environments HTTP has certain performance
characteristics that militate against its use for such a high volume
"trunk" link.

 

Actually we find this is the case with the OMA MLP protocol
specification as well. MLP is based on HTTP - for the same sorts of
reasons described above. In a model where there are many arbitrary
location application clients using the gateway location server, HTTP
makes sense. However, it turns out in practice that a standard
implementation is for an operator to have an application middleware
platform (which binds network functions such as location, SMS,
voice-response, etc.) together as application building blocks.
Applications are then hosted on this middleware and all the location
gateway sees is the middleware host as a single client which is trunking
many, and frequent, requests toward it on a single HTTP session. Each of
these requests has different response time requirements but the nature
of HTTP is such that the response to a request cannot be provided until
the responses to previous requests have been sent. This leads to an
unfortunate sub-optimal latency effect because responses cannot be
arbitrarily interleaved with requests.

 

The OMA solution to this is to define an asynchronous response model
using HTTP. Requests come in from the client and are acknowledged
immediately. When the response is cooked, the gateway becomes the HTTP
client and pushes the result back to the application. Correlation is
done using a transaction ID.

 

This is quite unattractive from an implementation perspective and
highlights the fact that certain implementation models benefit from
alternative transport protocols being available. In the case of HELD,
such "trunking" scenarios are better served by using BEEP as the
transport/session protocol than using HTTP.

 

So - after all those words - that is why relying on an informal
convention for URI encoding is not satisfactory - it assumes a
particular binding. Having the application protocol support the
semantics explicitly is more robust. And, as a final question, why
doesn't the use of such a convention for URI construction invite the
same sort of security issues that are being ascribed to the identity
extension?

 

Cheers,

Martin

________________________________

From: Marc Linsner [mailto:[e-mail]] 
Sent: Thursday, 22 November 2007 9:29 AM
To: Winterbottom, James; [e-mail]
Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

 

James,

 

In-line....

	 

	
________________________________


	From: Winterbottom, James [mailto:[e-mail]]

	Sent: Wednesday, November 21, 2007 3:42 PM
	To: Marc Linsner; Stark, Barbara; [e-mail];
[e-mail]
	Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

	Marc,

	 

	Suppose the identifier is a MAC address, since this has no
formal URI representation  then what? 

	 

[e-mail]
<mailto:macaddressofmarclinsnersworkstation-00-01-6C-CB-DF-01@accessprov
ider.net> 

 

IMO, formalization of such is not required as entities passing such
information have established relationships and can negotiate syntax via
that relationship.  If in fact it's standardized, it creates an attack
vector.

	 

	Suppose HELD is bound to a transport other than HTTP, such as in
http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-01, how are
the parameters simply added to the URI? Does it even make sense to do
so? 

	 

Hmm....HELD = HTTP enabled location discovery is bound to a transport
other than HTTP?

	 

	
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-06.txt
indicates that identifiers other than IP address will be required in
some scenarios. 

	 

LCP = location configuration protocol. Configuration of a host, not SP
OSS boxes.  Where draft-ietf-geopriv-http-location-delivery-03.txt does
not work is spelled out in that draft.  The draft works in ALL scenarios
except tunnels.  I'll accept that the security/privacy required by
3693/4 is met as is, but not with extensions.

	 

	 

	
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-03.txt
identifies the need, in some situations, for an outbound proxy to insert
location on-behalf-of the calling device. In this situation using HELD
requires a formal way to express how the Device is being identified, and
what the identifier represents. 

	 

 Not all requirements have technical solutions.  The phonebcp is
attempting to state that it's possible for a proxy to insert location,
it doesn't provide or require the 'how'.

	 

	Please read the draft
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte
nsions-04 before jumping on to the attack. 

	 

Yes, this drafts opens up several ways for someone other than a target
to gain knowledge of some other target's location. 

	 

	There are several architectures and deployments well underway
that require this work. The ABNF definitions in the extensions draft
have applicability beyond just HELD. 

	 

I realize Barbara's concern and offered an alternative, asking why it
doesn't solve her use case.  To state there are 'several' more adds
nothing to this thread. 

	 

	 

	    I don't see a need to delay this work further. 

	 

That's a surprise.

 

-Marc-

	 

 

	 

	Cheers

	James

	 

	
________________________________


	From: Marc Linsner [mailto:[e-mail]] 
	Sent: Thursday, 22 November 2007 4:54 AM
	To: 'Stark, Barbara'; [e-mail]; [e-mail]
	Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

	 

	Barbara,

	 

	Remind me again why this can't be accomplished by putting the
identifier in the uri?  ex: [e-mail]

	 

	Thanks,

	 

	-Marc-

	 

	 

		 

		
________________________________


		From: Stark, Barbara [mailto:[e-mail]] 
		Sent: Wednesday, November 21, 2007 12:17 PM
		To: [e-mail]; [e-mail]
		Subject: Re: [Geopriv] draft agenda: GEOPRIV @ IETF 70

		Robert,
		I think the HELD identity extensions is important. It's
needed for LIS to LIS communication, which is critical where the entity
who assigns the public IP address is not the same as the access
provider.
		Barbara
		
		----- Original Message -----
		From: Robert Sparks <[e-mail]>
		To: GEOPRIV <[e-mail]>
		Sent: Tue Nov 20 15:09:03 2007
		Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70
		
		Folks -
		
		We have 2.5 hrs in Vancouver (Friday morning). Based on
our chartered 
		work, list discussions, and agenda requests, here's the
agenda I'm 
		planning to follow:
		
		15m     Administrivia   Chairs
		30m     http-location-delivery  Mary (<- Lets finish
this one!)
		20m     Finishing geopriv-policy        Hannes/Cullen
		30m     LIS Discovery   James W
		10m     l7lcp-ps        Hannes
		20m     pidf-lo-dynamic Henning
		15m     dhcp-lbyr-uri-option    James P
		10m     civicaddresses-austria  Karl
		20m     Uncertainty and Confidence      James W
		10m     HELD Dereference        James W
		
		As usual, we have many other requests to talk about
other things - 
		please take those to the list for now.
		
		This is a draft agenda and we can change it. Let me know
if you think 
		I've missed something important.
		
		RjS
		
		
		_______________________________________________
		Geopriv mailing list
		[e-mail]
		https://www1.ietf.org/mailman/listinfo/geopriv

		*****

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

	 


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

	 

------------------------------------------------------------------------------------------------
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv