Subject: [Ecrit] draft-ecrit-framework-03 (comments on document content)

From: Matt Lepinski <[email-masked]>
Date: Thu, 25 Oct 2007 16:03:27 -0400

This is the first half of my review of draft-ietf-ecrit-framework-03. 
I've tried to separate my comments into "Comments on document content" 
(more substantive) and "Comments on document clarity" (more editorial), 
but the line between the two is blurry at times. (Note: "Comments on 
document clarity" follow in a subsequent email.)

Comments on document content
---------------------------------------
Section 2:  I believe there should be a reference to phonebcp somewhere 
in the introduction and an explanation of how the two documents fit 
together.

Section 3:  Given that the ESRP appears in both Figure 1 and Figure 2, I 
would recommend adding a bullet to the list (after paragraph 2 of 
Section 3) on how the ESRP fits into the call setup process.

Section 3:  I find Figure 2 very difficult to parse. Instead of an arrow 
diagram, consider just using a list of messages (as illustrated below) 
to describe the messages appearing in Figure 1.

[M1]: LCP request from Alice to configuration server (ask for location).
         LCP reply from configuration server to Alice (reply with location).
[M2]: SIP REGISTER from Alice to configuration server.
         200 OK (REGISTER) response from configuration server to Alice
[M3]: Initial LoST Protocol Query from Alice to LoST server (contains 
location)
        
(and so on ...)

Section 6:  The point of paragraph 6 seems to be that dispatch location 
must be accurate to within 3 cm (with high confidence) and let current 
measurement technology is several orders of magnitude away from being 
able to achieve this accuracy. It's not clear to me what conclusion we 
want readers to draw from this paragraph. It would be nice if we could 
provide some guidance to those building mobile systems regarding what 
they should do in the absence of location determination technology that 
meets emergency service needs.

(As an aside, I'm not sure where the 3cm number comes from. If I'm 
standing near a wall in my apartment and using my cell phone and my 
neighbor is standing near the same wall in his apartment with his cell 
phone, given that neither of us talk with our cell phones pressed up 
against the wall, it seems likely that our cell phones are about 60 cm 
apart.)

Section 6.2:  In the second paragraph, the document highlights the 
problem of multiple, contradictory, locations but doesn't provide any 
guidance on how to deal with the problem. I don't know that we ever 
reached concensus on the correct "default" behaivor for dealing with 
multiple locations, but I think that either framework or phonebcp should 
provide some guidance on reasonable default behaivor. (And if the text 
ends up in Phonebcp, I would probably put a reference in framework.)

As an aside, I personally agree with Barbara's suggestions in: 
http://www1.ietf.org/mail-archive/web/ecrit/current/msg04407.html

Section 6.6:  In paragraph 4, the document correctly identifies the 
there is a time-vs-accuracy trade-off in many location determination 
technologies. However, the guidance that it provides is unclear. The 
text seems to say both that when there is a 'quick fix' available that 
it is preferable to wait, but also that 'quick fixes' take too long and 
therefore one should not wait. I'm not sure what the best advice is to 
give to a reader who is facing a time-vs-accuracy trade-off, but it 
would be nice if we could provide at least some rule of thumb.

Section 6.12:  I don't think that Paragraph 2 (on DHCP security) belongs 
in this section. First, it seems odd that it specifically discusses 
security for DHCP and not for other location configuration protocols 
(e.g. HELD). Second, it seems that this type of security text would 
better fit in the Security Considerations section of the document. I 
would suggest text like the following:
"To avoid spoofing attacks, mechanisms for authentication of the 
location configuration server by the device SHOULD be used. In 
particular, when DHCP is used as an LCP, the security mechanisms of RFC 
3118 should be used, and when HELD is used as an LCP server-side TLS 
authentication should be used."
(Note: I haven't read the security considerations section of LLDP-MED 
recently to know if any particular authentication mechanisms should be 
called out in this document.)

In paragraph 3, I think a distinction needs to be made between 
confidentiality (encryption) mechanisms and integrity protection 
(signature) mechanisms within S/MIME. In particular, RFC 3261 specifies 
the use of multipart/signed for integrity protection of SIP bodies. This 
mechanism does not "obscure" location and should not interfere with 
intermediate proxies who need to route based on location (or SDP media 
types). Therefore, I would suggest text such as:
"Confidentiality mechanisms such as S/MIME encryption of SIP signaling 
[RFC 3261] cannot be used because they obscure location. Only hop-by-hop 
confidentiality mechanisms such as TLS may be used."

Section 9.1:  The first paragraph indicates that emergency calls are 
subject to the requirements of RFC 3693. I think it may be worth noting 
that RFC 3693 explicitly makes an exception for the emergency case. In 
particular, RFC 3693 indicates that for non-emergency calls, if I can't 
authenticate the party recieving location information, then I shouldn't 
send the location information (unless of course, I have a rule that 
states "it is acceptable to send location information to anyone"), and 
we don't want the reader to infer that this is also the case with 
emergency calls. I think we've agreed that for emergency calls, whether 
to send location to a PSAP that cannot be authenticated is a matter of 
local policy, but that generally such policy will indicate that location 
should be sent (even without authentication).

I believe it is inappropriate for this section to suggest the use of 
SIPS. Draft-ietf-sip-sips clarifies that SIPS should be used only when 
the desired outcome is for call setup to fail if the request cannot be 
sent over TLS for every hop. This is certainly not the desired outcome 
for an emergency call. For an emergency call, it is generally quite 
important that call setup suceed even if some pair of proxies along the 
signaling path fail to establish a TLS connection. Draft-ietf-sip-sips 
(Section 3.1.3) makes it clear that in such cases, the correct behaivor 
of the UAC is target the request for a SIP URI and sent it to the 
outbound proxy over a TLS connection. (A proxy that recieves a SIP 
request over a TLS connection should then attempt to send it over a TLS 
connection for the next hop whenever possible.)

Note: There is also TLS-related text in Section 6.12, I would consider 
deleting the instructions on TLS use in Section 6.12 unless there is a 
good reason to repeat the text.

Section 14:  In the second paragraph, merely suggesting the use of S-RTP 
without guidance on key management is likely to produce bad results. 
(For instance, a device manufacturer who reads this document might 
decide that for Media security the UAC will send an offer for an S-RTP 
session that includes the first message of a MIKEY RSA-R exchange. 
Unfortunately, if the PSAP doesn't support this particular mode of 
MIKEY, then the S-RTP key cannot be established and call setup fails. 
This is obviously a very bad result for an emergency call.) Therefore, I 
belive that this document should either provide guidance on how to 
establish S-RTP keys (e.g. DTLS-SRTP) or else should not suggest the use 
of S-RTP.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit