ECRIT Interim Meeting
=====================

The GEOPRIV and ECRIT working groups organized a joint interim meeting.
These meeting minutes only capture the ECRIT part of the meeting (although the Geopriv session was relevant for ECRIT as well).

When: 2005 May 17 13:00-17:30
2005 May 18 08:30-17:30

Where: Columbia University
Dept. of Computer Science
450 Computer Science Bldg.
1214 Amsterdam Avenue (close to 120th St.)
New York, NY 10027

Participants:

Hannes Tschofenig
Henning Schulzrinne
Marc Linsner
Roger Marshall
James Winterbottom
Brian Rosen
Tom Taylor
Nadine Abbott
Tom Phelan
James Polk
John Morris
Mika Ylianttila
Andrew Newton
Ted Hardie
Jon Peterson
Patti McCalmont
Allison Mankin
Martin Dolly
Shida Schubert
Christopher Crawford

Pictures can be found at: http://www.ietf-ecrit.org/Interim2005/

Agenda Bashing
=====================

Slides can be found at: http://www.ietf-ecrit.org/Interim2005/ecrit.ppt

Hannes starts with a short summary.

Requirements document:
Some reqts already met, others out of scope of ECRIT.
Objective is to sort these out, shorten document

Threats document: challenge is that threats document is not focussed on a specific solution, hence difficult to be concrete. Specific soln eliminates some threats, brings out others.

Hannes mentions that he does not want to be the editor of this document.
Editorship: Brian Rosen volunteered to take over.
Tom volunteered as well.

Requirements for Emergency Context Resolution with Internet Technologies
http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-00.txt
Roger Marshall, Henning Schulzrinne
=================================================================

Roger starts with the consolidation of the requirements.

Slides can be found at http://www.ietf-ecrit.org/Interim2005/Consolidation_requirements_pres_051705.ppt

Worked to merge in reqts from other sources (specified on charts).

No inclusion of SIP specific architecture doc (draft-schulzrinne-sipping-emergency-arch-02)
Try to be general rather than SIP specific

Late cmments from Stastny, Polk, update Japanese reqts from Arai. (Already folded in earlier draft to consolidated document.)

Procedural point (Ted): considering only numberted reqts, not those in intro? (agreed). Hopes intro will be agreed.
Clarification: can talk about terminology.

James P comments
---------------------
#3: IAP vs. AIP: sensitivity to broader emergency calling problem. But IETF deals only with Internet. Brian argues may not be totally intelligible to other groups. Tom T and Jon agreed that IAP and AIP designate potentially different entities.
Agreed by hum to use "Internet Access Provider (IAP)" as the entity that provides physical access to the Internet.

Jon: can we raise level of granularity?

Looking at Reqts directly.

R5: Henning will rewrite. His explanation made sense.

R6: Ted doesn't see as relevant to charter. Henning says ECRIT should not break SIP totally (e.g. by requiring use of a new URI type). Ted sees that incremental deployability will fall out of other provisions in charter. Jon agrees with Henning that at some point WG has to decide how architecturally restrictive the work of the group has to be. Ted argues that the charter is fairly clear (and general -- data can be inserted at any sensible point in call path).
Ted will send text for counterproposal. Brian feels there is more to it, but will wait for text.

A1: Mark thinks there has to be a specification of where in the call path the "universal identifier" will be used. Henning notes that the emergency nature of the call has to be recognized all the way to the PSAP.
Henning's main concern that issue not ping-pong between WGs. Jon gives AD assurance that SIP will do its part.
Reword A1 in particular to make clear the recognizability as the key reqt.

A1 and A3 can be merged. Henning suggests dimensions are recognizability, marking of call.

A4: Brian asks how local identifiers are recognized. Configuration. But no configuration reqt. Basically want to drop local identifier reqt to avoid having to configure every European proxy to recognize 911.
Brian makes point that mapping is same for all protocols. On the other hand, since lookup is location-dependent, it becomes a protocol reqt.
Henning has ideal vision of device conforming conventions both of owner and of borrower. Ted doesn't see this an IETF issue because it is an user interface issue. A fortiori, doesn't belong in ECRIT.
Agreed: not an ECRIT reqt. (But someone should solve it.)

A5 also drops out.

A6: Ted had relevant comment.
A7: drops out

UA-inserted vs. UA-referenced, Proxy-inserted: to be inserted into SIP-loc-reqts doc. (References fit better into SIP architecture)

L1: James P points out potential issues for references in the case of large enterprise environments where IT would like to limit the number of pinholes for location queries to 1 or 0. Would like language strengthened to encourage IT to support such a method of operation.

Suggestion that issues like this be captured in a separate document.
Agreement: add last-priority milestone to capture this sort of thing.
Jon warns hands-on joint effort rather than throwing stuff over the wall to other groups -- IEPREP disappointments.
Affects reqts L1-L3

Jon thinks a piece of L3 affecting the mapping has to be considered by ECRIT.

L4 not an ECRIT problem -- to the other document. James suggests unifying "certifiable", "verifiable", and "valid" if they continue to be used.

L5: a headache to GEOPRIV. Jon's proposal, agreed by Ted: resolution to single location should be done before mapping and routing. Brian came up with two legitimate use cases. His main concern is to have a deterministic rule for dealing with multiple addresses.
Henning: really not a protocol issue.
Jon: key point is to agree that only one address will be used for routing.
Mark: but dealing with reqts here. Is there a reqt to deal with more?
Agreement: routing protocol will have to deal with just one address.
L5 goes to other document, but has to be changed taking account of L11 and preceding discussion. (i.e. provide advice on how to select among multiple locations)

L6: Discussion over (possible) role of protocol in validation and what this might mean in terms of reqts. Ted points out the discussion suggests two separate protocols, one for pre-validation, one for routing. Use case for routing: could have default PSAP (e.g. because town is covered by only one) for invalid location; validation protocol would be required to return failure.
Clarifying text needed on validation, but requirement accepted that it be possible to use protocol for both validation and routing.

L7: out of scope

L8: out of scope.

L9: rewrite to say protocol shall accept altitude as a component of location. Mark suggesting a more general approach: protocol/mapping must be able to take into account all location-specific [added Wed. when discussing I20] PIDF-LO fields. Nadine wants to provide text -- will talk about extensibility.

L10: agreed that it should not be totally open. Base it on the PIDF-LO profile, which itself needs elaboration (currently mentions only WGS-84).

L12: out of scope

L13: rewrite to say mapping function is available before and after call is initially routed. Use case is updated location information taken by PSAP and requiring call transfer. Phrase: mapping fcn can be invoked independently of call setup.

L14-19: gone.

Editorial note: requirement numbers will not be reused so these reqts can be resurrected if necessary.

L20: already gone.

L21: operational doc

L22: gone

L23: GONE

L24: Ted: real reqt is that user of mapping function be able to protect location info from eavesdropping
Move to security.

===============================================================================

(Wed. am)

Discussion -- tried to understand L25. Out of scope.

L26: Andrew: bad reqt even if it can be achieved. Shouldn't be blocking on emergency calls.
Hannes thinks it can be done.
Nadine: endpoint should at least reachable within the access network.
Not an ECRIT issue, policy.
Henning: what tools do we provide to let people enforce policy?
Brian: discussion misdirected.
Ruled out of scope.

L27: out of scope.

L28: OK, obvious for push model. Additional spin: using protocols should pass on the original PIDF-LO even if info is added.
James P to rewrite and present to list.

L29: out of scope.

L30: GEOPRIV concern.

Section 6: intro
Discussion of terminology, decided the term would be "PSAP", not "IP PSAP", "I PSAP", "ECT".
Para beginning "Note that the first proxy ..." will be deleted.

I1: change "correct" to "the PSAP responsible for this routing area".

I2: to BCP.

I3: Henning: real need is for ability to do incremental refinement of routing. Henning to provide text.

I4: use case: emergency number dialled on campus -- now campus emergency has to redirect serious cases to city. Lots of architectural implications. Need to be able to signal back to protocol user (not normally end caller, but policy in proxy) which URI is for what.
Henning and Patty drafting E-mail. Will add that some countries only need country-level resolution. [added as a result of discussion of I21]

I5: out of scope.

I6: UI out of scope.

I7: can make traceability a reqt on the mapping, but the user protocol may be unable to use the info.
Brian to send text to make this a reqt on the mapping protocol.

I8: terminology to be cleaned up. Reqt could be spelled out: caching + possible to have multiple instances of mapping service.
Henning creating new text.
Brian reprise: prefer proven systems over new ones.
Ted: robustness a function of the application -- a particular protocol may be inherently robust, but not necessarily in a particular app.
Concern is not to define robustness in a reqts doc, hence move to make reqts more specific.

I9: merged into rewritten I8

I10: ref R6. Brian's concern -- be able to deploy database in stages of resolution (e.g. city wide fol by neighbourhood). Brian rewriting.

I11: gone.

I12: useful, but no direct effect on mapping fcn. Move to info doc.

I13: gone.

I14: covered by L9.

I15: BCP

I16: BCP

I17: BCP. Mark asks if maintenance of mapping DB is in ECRIT scope. Who can add records to DB, by what mechanism? Ted rules currently out of scope, IESG might reconsider if mapping protocol choice has a strong implication for maintenance. Henning proposes sentence to add to intro to make this clear.
Brian: need standardized method since distributed DB.
Tom: difference between standardization and coordination -- DB is local.
??: question whether ECRIT product should be reusable for loc-based services.
Ted: OK as by-product, shouldn't distort output.


I18: BCP

I19: BCP -- allied to I17 discussion. Could come into scope depending on design.

I20: GEOPRIV issue -- PIDF-LO capability reqt. DB design rather than protocol issue. L9 effectively covers. Brian thinks there may be BCP issue, could use this text.

I21: implied in I3.

I22: BCP

I23: not right. Delete.

I24: gone.

I25: OK

I26: BCP

I27: satisfied if I3 covered. BCP.

I28: Implies unpredictable lifetime for cached routing entries. TTL indication should be part of returned route, but usage is a BCP issue.

I29: covered.

I30: security

I31: reqt for protocol to provide alternate routes. Ted will rewrite to make more precise.

I32: gone

I33: gone

I34-35: reqt on the DB. BCP.

I36: operational, merge with traceability, BCP (ref I7)

I37: out of scope

I38: no reqt

I39: merge with L13



D1: Henning to rewrite.

D2-3: security

D4: out of scope (may be relevant to security if design brings into scope)

D5: OK, though motherhood. Need something numeric?

D6: James P: if kept, should be open to UA, proxy, or other server. Henning: sees as covered by I4.

D7: not sure -- investigate later. Henning thinks it is covered by "queries can come from anywhere". Ted: sees possible reqt that no single server has to have global knowledge. Brian: mapping query should never fail. Separate reqt. Henning to send text.

D8: OK, but must be only one mandatory to implement. Motivation text goes. (Combine with D9)

Section 8 in total goes to info doc.

Section 9
---------

S2 BCP. S3 per I12. S6 already covered (ref I7). S1, S4 for security. S5 BCP? S7 BCP S8 BCP
S9 tracking and tracing covered (ref I7).

Section 10
----------

SD1-4: Brian wrote section. Basically says routing query could return more than routing info. Express as extensibility and versioning reqt. Another reqt is to ignore ununderstood info. *** Tom to provide text.

Remainder of section out of scope.

Section 11
----------

Superseded by security doc.


===================================================================

Security Threats and Requirements for Emergency Calling
http://www.ietf.org/internet-drafts/draft-tschofenig-ecrit-security-threats-00.txt
H. Tschofenig, H. Schulzrinne, M. Shanmugam
==========================

Slides can be found at: http://www.ietf-ecrit.org/Interim2005/ecrit-security.ppt

Henning discusses the slides.

Reqts may be out of scope -- draft done before reqts reviewed.

Terminology intro -- base on reqts

Asserted loc info: someone vouches for it

Chart 2: basic architecture: loc provider, IAP, ...

Chart 3: participant-visible threats -- the usual ones

No direct monetary gain, so threat model focusses on disruption of service
-- infrastructure failure
-- tying up call takers
-- false dispatching emergency responders
Ted: could this be the standard "DOS" category? Doesn't want to see unnecessary reinvention.

Difference in PSAP case: PSAP doesn't care who you are so long as you are not lying about the loc or nature of the emergency.
-- identification needed for accountability, but not needed to provide service
Jon: not particularly different from general authentication reqt
Henning: difference in behaviour
Jon: concedes routing system clearly doesn't need to know who you are. Remainder o9f discussion not relevant.

Chart 4: layers of defence

Chart 5: threats

Chart 6: authentication
-- discussion of what the real identification reqt is. Seems to agree with Jon's point.

Chart 7: detailed security threats to caller
-- confidentiality
-- mod of config info
--
Standard stuff

Chart 8: infrastructure threats
- second part out of scope

Chart 9: caller identity spoofing
-- reqts

Chart 10: location spoofing
-- various proposed models, already discussed
Timestamp and identity
-- for traceback
Mostly out of scope

Location spoofing threat mediation
-- again mostly out of scope, BCP at best
Ted: be very careful that efforts to prevent local area collusion do not prevent mediated retrieval of directory info.

Chart 11: Impersonating a PSAP
-- out of scope

Ted: is channel security sufficient, or is something like CMS needed?
Henning: detailed analysis -- assurance at three levels. Implicit assumption of transitivity -- user trusts whatever the routing service trusts.
Non-repudiation?
Henning: do we want to worry about whether the server with the desired role (area of authority) has been reached? (Final bullet on chart?)

Chart 12: open issues

Editorial (Henning): What do we do with reqts: add to reqts doc or retain with threat description?
Henning: only one of these charts relate to protocol reqts -- move to general reqts doc -- but continue this doc as part of BCP effort. Less time critical.
*** Hannes takes action to identify protocol-specific security reqts and report them to the list.
Patti: notes relationship to SIP spam issues. Henning: but counter-techniques not applicable.

==========================

Rest of meeting
1. James P. additional reqt
2. Discussion of some candidate protocols and points of difficulty

James P.
========

Really not an ECRIT reqt, but needs to be kept in mind
Sweden: within the country, a law: when a person in Sweden calls 911 equivalent, two locations have to be passed: location of caller, billing location of caller.
Implication: conveyance in user protocol has to be able to indicate semantics so the right location can be used for routing.

Discussion: May be simply a binary indication: "use" or "don't use".
Could be multiple tuples.
Content_Disposition not good when you have multiple parameters.
*** Henning takes action item to provide text. BCP.

Candidate Protocols
===================

An IRIS Schema for Emergency Service Contact URIs
http://www.ietf.org/internet-drafts/draft-hardie-ecrit-iris-00.txt
Ted Hardie, Andrew Newton, Hannes Tschofenig
---------

Andrew: Successor protocol to whois query protocol, which was badly broken. Backwards compatibility was not a reqt.

XML-based query-response protocol. ECRIT would develop new schema within the framework.
Selling points: XML-based, ...
Two transport alternatives, one of them light weight.
ID published this last week: formal syntax, some design rationale.

Abstract indicates basic premise: geo or civil input, URI output.

Brian: explain referral mechanism.
IRIS has two types: entity reference (redirect to another server), INVITATION TO ITERATE.
One approach to discovery: assume that any IRIS server can identify the starting point server to handle the query.
Other: more like DDDS.
Were not ready to make a recommendation, pending reqts analysis

Henning: minimize global configuration. Don't want ICANN-like body responsible for distributing info to world, or E-mail-like mechanism that if missed, results in out-of-date entries.
Need either reliable distribution mechanism or discovery mechanism.
Ted: based on reqts, probable approach might be DNS+NAPTR for starting point, intra-ECRIT system for remainder.
Henning: DNS sounds good for country-level resolution. Major issues below country level.
Ted: always easier to start with civil rather than geo. Would need to designate for base servers that they must be able to convert geo to country.
Brian: one problem: disputed areas. May also get hint at country from network. Final point: need incredibly accurate database to convert from geocode to civic address.
Distinction: starting point for query vs. starting server. Latter is what Ted intended.
Henning notes caching will speed up responses, particularly at higher levels. Caching avoids round trips. Recursion reduces magnitude of round trip.

Emergency Call Information in the Domain Name System
draft-rosen-dns-sos-00.txt
Brian Rosen
----------------------------------------------------

DDDS. DNS keys based on civil address. Delkegation mechanism nearly perfect. Geo is a bit of a bother, uses zone transfer to fetch polygons. Initial query key is lat+long+country.
Andrew: note limit of 255 bytes in query. Problem with international domain names (multi-byte queries).
Ted: need to indicate semantics of each field of query string -- town names matching stret names otherwise a problem.
Brian: answers to specific items.
Ted: yes, but pushing limits of DNS, likely to run into a stopper.
Henning: has been demonstrated in CSU labs.
Ted and Andrew: case where one would get spiral routing between DNS servers (fairly rare) could screw up the DNS infrastructure unless handled properly.

Jon: really nervous, given tenor of discussion and expertise of discussants, that this is outside the domain of applicability of DNS. First step in exploration has to be to get review of concept by guardians of DNS.
Ted: would have to give DNS directorate clear assurance that behaviour of DNS infrastructure would not be changed. He will give contacts of early reviewers if required.