ECRIT Interim Meeting
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
Pictures can be found at: http://www.ietf-ecrit.org/Interim2005/
Slides can be found at: http://www.ietf-ecrit.org/Interim2005/ecrit.ppt
Hannes starts with a short summary.
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
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
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
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
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
Editorial note: requirement numbers will not be reused so these reqts can be
resurrected if necessary.
L20: already gone.
L21: operational doc
L24: Ted: real reqt is that user of mapping function be able to protect location
info from eavesdropping
Move to security.
Discussion -- tried to understand L25. Out of scope.
L26: Andrew: bad reqt even if it can be achieved. Shouldn't be blocking on
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
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
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.
I12: useful, but no direct effect on mapping fcn. Move to info doc.
I14: covered by L9.
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.
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
I21: implied in I3.
I23: not right. Delete.
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.
I31: reqt for protocol to provide alternate routes. Ted will rewrite to make
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.
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
Section 8 in total goes to info doc.
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).
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.
Superseded by security doc.
Security Threats and Requirements for Emergency Calling
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
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
Chart 7: detailed security threats to caller
-- mod of config info
Chart 8: infrastructure threats
- second part out of scope
Chart 9: caller identity spoofing
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.
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
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
Rest of meeting
1. James P. additional reqt
2. Discussion of some candidate protocols and points of difficulty
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.
An IRIS Schema for Emergency Service Contact URIs
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
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
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
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
Distinction: starting point for query vs. starting server. Latter is what Ted
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
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
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