Transcript geopriv-3
RELO: Retrieving End System Location Information draft-schulzrinne-geopriv-relo-03 Henning Schulzrinne March 2007 IETF68 - GEOPRIV 1 Motivation • Layer-7 mapping of identifier to location – typically network termination equipment • DSL modem, 802.11 AP • Believed to satisfy L7-LCP requirements • Narrowly-focused protocol -- one purpose – make it easier to specify interoperability • Since just mapping, could map SNR measurements to location… March 2007 IETF68 - GEOPRIV 2 Discovery • Currently, S-NAPTR – should probably be U-NAPTR – domain from host configuration (DHCP) or reverse DNS March 2007 IETF68 - GEOPRIV 3 Query • Parameters: • Just send HTTP GET – TLS RECOMMENDED • Uses GET parameters, as in – http://example.com?by=value &type=civic March 2007 – – – – – – – – – – – IETF68 - GEOPRIV by: value or reference within: time willing to wait type: civic or geo retransmission-allowed: yes/no retention-expiry: usage rule external-ruleset: usage rule note-well: usage rule url: URL to renew expires: LO/LR should expire secret: secret for modification assert: LO to store 4 Identifiers • • • • Default: IP address of request mac: MAC address cdp: Cisco Discovery Protocol string msap: MAC service access point (LLDP) March 2007 IETF68 - GEOPRIV 5 Operations • Retrieval OBO/... LIS-LIS just variants of LbyR – civic or geo, value or reference • Renewal of reference lifetime – provide URL and secret • Assertion – provide LO for storage and/or signature March 2007 IETF68 - GEOPRIV 6 Response • Returns location object or URI (reference) – text/uri-list – acceptable location types indicated by Accept header • Uses HTTP Expires header to indicate validity • If error, use HTTP response – sufficient for error detection, with HTTP response body • To subscribe to location, insert Subscribe HTTP header (and maybe Event) – see SIP configuration framework for HTTP Event header March 2007 IETF68 - GEOPRIV 7 Design decisions • No notion of context -- stateless – no need for state maintenance • PIDF-LO (or any other future LO) • First-party retrieval (mainly) – reduce privacy risks • Specify discovery mechanism -- see related draft – use S-NAPTR (or U-NAPTR) via host name • Allow other identifiers • Uses HTTP error codes and status line, rather than define own • Subscribe URL in response header – separate discussion (tactical and technical) March 2007 IETF68 - GEOPRIV 8 Requirements • L7-1: Identifier choice – several, extensible • L7-2: Mobility choice – subscription or polling • L7-3: Layer 7 and Layer 2/3 Provider Relationship – none assumed • L7-4: Layer 2 and Layer 3 Provider Relationship – satisfied • L7-5: Legacy devices – satisfied March 2007 IETF68 - GEOPRIV 9 Requirements • L7-6: VPN awareness – prior to VPN attachment • L7-7: Network access authentication – none assumed • L7-8: Network topology unawareness – doesn’t care March 2007 IETF68 - GEOPRIV 10