Subject: [Ecrit] Review of phonebcp and framework

From: Richard Barnes <[email-masked]>
Date: Fri, 10 Aug 2007 12:54:35 -0400

Draft:  draft-ietf-ecrit-phonebcp-1, draft-ietf-ecrit-framework-02
Reviewer: Richard Barnes
Review Date: 9 Aug 07

Security / Privacy Concerns:
------------------------------------------------------------------------
* I recommend consolidating the two Security Considerations into a 
single section (with the other document referring to it).  The 
appropriate document would seem to be the phonebcp, so that it can set 
normative standards.

* One threat that's not addressed is the one introduced by phonebcp's 
recommendations about call termination, namely that if a phone gets a 
call from another AOR in the same domain as the PSAP, then it should 
drop its current call and take the new one.  This policy introduces a 
denial of service attack: An attacker can send an INVITE with a spoofed 
AoR and force emergency callers to disconnect from PSAPs.  How were the 
authors thinking about dealing with this?

* The security considerations should refer to existing (or planned) 
ECRIT and GEOPRIV documents about security, e.g., 
draft-ietf-ecrit-security-threats, and the forthcoming GEOPRIV security 
document(s).

General Comments:
------------------------------------------------------------------------
* The "division of labor" between the two documents is confusing -- 
there's a lot of descriptive, non-normative text in phonebcp, and the 
framework has a lot of "must"s in it, even if they're not in all-caps. 
I would like to see a clearer division here: The phonebcp should 
consolidate all required behaviors, with just enough motivating 
discussion to get by.  The framework should be purely narrative, 
describing how entities compliant with the phonebcp cooperate to 
accomplish emergency calling.

* I would also like to see a clearer structure to the document; right 
now the text seems to ramble.  Bonus points if the structure is 
consistent between the two documents to facilitate cross-referencing.  I 
would suggest a refinement on what the documents already do: Walk 
through the steps of an emergency call
1. Positioning
2. Dialing / initiation
3. Routing
4. Media
5. Dispatch
In the phonbcp, describe in implementable detail the required behaviors 
for all entities involved.  In the framework, describe how these 
behaviors fit together.

* It's been said before, but I agree with the idea of grouping 
requirements in the phonebcp by the entities they apply to: UA 
requirements, access network requirements, proxy requirements.  Even if 
this is done in an appendix, it will help implementors know easily what 
they need to do.

* Something that seems to be missing is a discussion of how the endpoint 
chooses the LCP that it uses to get its location.  Does it do all of 
them in parallel?  Does it try in serial until it succeeds?  Does it 
just do everything, and collect the results from the ones that succeed?

* I agree with Alexander's questions about document status.  ISTM that 
the phonebcp should be Standards Track, while the framework should be 
Informational.

* I don't understand the purpose of the sections on "networks that 
control every endpoint".  When does this happen in real life?  I would 
like to delete these sections, since they pose the risk that people will 
read them as a "get out of jail free" card for networks that don't 
really fit the description.

* Considerations about VPNs and NATs need to be tightened up.  Neither 
"VPN" nor "NAT" is a term with a well-defined, universal meaning, so 
this document needs to give them a definition before describing how they 
can screw things up.

* References to draft-rosen-iptel-dialstring should be to RFC 4967. 
However, I think tel: URIs are appropriate in this case.

* Neither document makes a distinction between location used for routing 
and location used for dispatch, even though these are very different use 
cases.  In my localized comments, I've suggested a couple of places 
where this is relevant, but this should be noted throughout.

* There are many places where the documents are too terse, so that a 
reader who doesn't know what the author means can't decipher it.  For 
example, in section 5.7 of the framework, it says "Authorization of 
subscriptions is for future study".  This sentence provides no useful 
information to someone seeking to understand the ECRIT architecture, 
much less someone who's not aware of issues surrounding authorization of 
SIP subscriptions (which I expect many PSAPs will not be).  This is a 
major issue for the phonebcp, which is describing specific things that 
have to work right for a call to succeed -- here things have to be 
described in sufficient detail to be implemented.

* References between the two documents should be more specific, 
referring to section numbers instead of to the document as a whole.

* Many places in both documents use language of valuation where 
technical distinctions are more meaningful.  For example, section 5.3.1 
of the framework says that user-entered location is "inferior to" other 
forms, when in reality the distinction is that it's "less reliable" -- 
it may be superior in some scenarios, e.g., where it's infeasible to use 
automated techniques.

Editorial Comments and Nits:
------------------------------------------------------------------------
See highlighted edits in attached PDF files.
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 13 Aug 2007 10:49:32 +0200

Hi Richard, 

Thanks for your review. A few comments below:

> -----Ursprüngliche Nachricht-----
> Von: Richard Barnes [mailto:[email-masked]] 
> Gesendet: Freitag, 10. August 2007 18:55
> An: ECRIT; Brian Rosen; James M. Polk; Henning Schulzrinne; 
> Andrew Newton
> Betreff: [Ecrit] Review of phonebcp and framework
> 

I am not sure whether we will be able to deal with security threats (onces that need to be mentioned beyond the ECRIT security threats document) in an extensive fashion in this document. 

Maybe we should just high-light a few very important aspects without going into a full threat analysis. 

This is mainly a framework document that describes the big picture. 

> draft-ietf-ecrit-security-threats, and the forthcoming 

That's a useful approach.

> General Comments:
I agree with your observation. The framework document should not use RFC 2119 language.

> for all entities involved.  In the framework, describe how these 

I suggested to structure the phone BCP according to the entities so that they can actually be referenced. 

> this is done in an appendix, it will help implementors know 

Good. 

> just do everything, and collect the results from the ones 

Good point. 

> the phonebcp should be Standards Track, while the framework should be 

Correct. 

> control every endpoint".  When does this happen in real life? 

Happens in GSM networks today.

>  I would 

There are other documents defining these terms. Maybe we just reference them. 

> However, I think tel: URIs are appropriate in this case.
Good to hear that this document is already RFC. I was already worried about the potential dependency. 

> where this is relevant, but this should be noted throughout.

We need to make this distinction. 

> described in sufficient detail to be implemented.
Agree. 

> referring to section numbers instead of to the document as a whole.

I fully agree. 

> it may be superior in some scenarios, e.g., where it's 

Ciao
Hannes

---

From: Richard Barnes <[email-masked]>
Date: Mon, 13 Aug 2007 13:48:20 -0400

Hannes,

Thanks for all the agreement :)

A few responses inline...

> This is mainly a framework document that describes the big picture. 

The phonebcp is a normative document that defines the behavior of 
elements participating in the call.  In particular, it defines certain 
behaviors (namely, the "disconnect when you get another call" behavior) 
that create new vulnerabilities not addressed elsewhere (to my knowledge).

Since the phonbcp is the document that introduces the vulnerability, it 
seems like it should say something about how to mitigate it.

> I suggested to structure the phone BCP according to the entities so that they can actually be referenced. 

I think that needs to happen as well -- I like the compromise position 
of doing both.  For the exposition, use the "story of the emergency 
call", but collect things by entity at the end for quick reference.

> Happens in GSM networks today.

Kind of.  Like the current framework draft mentions, the GSM network 
controls the specifications of devices connected directly to it, but 
doesn't necessarily control what's behind it.  To use Brian's example, I 
can use my GSM phone as a gateway for the Ethernet LAN in my truck.  Or 
use the satellite endpoint in my rental car as a gateway to an 802.11 
network.

Now, what goes on in walled gardens in general is not something that the 
IETF worries about.  Within a closed network, everyone can run HTTP on 
port 666 for all the IETF cares.  So I'm tempted not to say anything 
about this situation.

However, the problem is that for emergency calls to work for "indirectly 
connected" endpoints, there will be a need to gateway location 
information through from the GSM network (say) to the LAN.  So whatever 
format the walled network uses, it needs to be compatible with the IETF 
standards (in case it gets gatewayed to a standards-compliant network).

So, what I'd like the document to say is something like this:
"
In principle, within a closed, private network, any protocol and any 
location format can be used to configure endpoints with location 
information.  However, these endpoints are capable of acting as gateways 
for further networks, which may use the closed network as a source for 
location information.  Thus, even closed, private networks MUST 
distribute location information in IETF defined formats (e.g. PIDF-LO or 
a DHCP format), and SHOULD use IETF LCPs, if they wish to support 
emergency services for their subscribers.  This allows for endpoints of 
the closed network to exchange location information with other endpoints 
through IETF protocols with a minimum of conversion between formats.
"

> There are other documents defining these terms. Maybe we just reference them. 

Could you provide a pointer to these?  I also think that what these 
documents have in mind (for the term VPN in particular) is perhaps a 
specific type of VPN.

Thanks,
--Richard