here - Hannes Tschofenig
Download
Report
Transcript here - Hannes Tschofenig
GEOPRIV Layer 7 Location
Configuration Protocol; Problem
Statement and Requirements
draft-ietf-geopriv-l7-lcp-ps-00.txt
Hannes Tschofenig, Henning Schulzrinne
IETF 68, Prague, March 2007
Status: Many WGLC Comments
Areas of Comments:
Editorial
Modify Document Structure
New requirements
ToC
1. Introduction
2. Terminology
3. Scenarios
3.1. Fixed Wired Environment
3.2. Moving Network
3.3. Wireless Access
4. Discovery of the Location Information Server
5. Identifier for Location Determination
6. Virtual Private Network (VPN) Considerations
6.1. VPN Tunneled Internet Traffic
6.2. VPN Client and End Point Physically Co-Located
6.3. VPN Client and End Point Physically Separated
7. Location-by-Reference and Location Subscriptions
8. Preventing Faked Location based DoS Attacks
8.1. Security Threat
8.2. Discussion about Countermeasures
9. Requirements
10. Security Considerations
10.1. Capabilities of the Adversary
10.2. Threats
10.3. Requirements
11. IANA Considerations
12. Contributors
13. Acknowledgements
14. References
Delete?
Moved into a
separate
document
Terminology Section
We use the term "Location Information Server (LIS)“
but we don’t define it.
We discussed this aspect in Dec. 2006 without a
result.
Should we fall back to RFC3693's "Location Server
(LS)"?
Scenario Section
Minor update based on comments. Clarifications
mostly.
Scenarios are not meant to be exhaustive.
Requirements Section
Add a reference with regard to the discovery procedure.
New requirements:
LIS-to-LIS & On-behalf-of
Both have the characteristic that they allow the location
request to be able to support other (typically access
technology dependent) forms of client identifier than the IP
address.
Input / Output parameters are not known.
Need for a Quality of Service response time parameter
Not sure whether they are LCP specific or should be moved to
the Location-by-Reference requirements document.
Location-by-Reference
Move requirements to draft-marshall-geopriv-lbyr-requirements00.txt ?
This would effect potentially affect the following text:
The reference MUST be valid for a limited amount of time.
The reference MUST be hard to guess, i.e., it MUST contain a
cryptographically random component.
The reference MUST NOT contain any information that
identifies the user, device or address of record
The Location Recipient MUST be able to resolve the reference
more than once (i.e., there is no implicit limit on the number of
dereferencing actions).
Possessing a reference to location information allows a
Location Recipient to repeatedly obtain the latest information
about the Target with the same granularity.
The Target MUST be able to resolve the reference itself.
Operational Considerations
Dan Romascanu:
“
The Internet-Draft does not include any operations or
manageability considerations or requirements. At a
minimum I would suggest that consideration is given to
whether there is need for any prior configuration of
hosts or nodes or LISs involved in the protocol, if yes
how this will be done, what is the level of traffic this
protocol is supposed to generate in a network, are
there any dependencies or impact on other protocols,
any means of monitoring the status of the entities
running the protocol and any faults specific to this
protocol to be reported to an operator.
“
Has never been raised before. What should we do?