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

From: "Brian Rosen" <[email-masked]>
Date: Fri, 16 Nov 2007 16:53:28 -0500

Matt

I have incorporated all of your suggestions, in one way or another into
-framework-04, except as that in your comment on 6.6, I point out that
phonebcp does provide a recipe (250 ms unless substantial improvement can be
obtained in less than 3 seconds).  Of course, there is no magic here and
these numbers are reasonable, but not precise.  So, I did not make any
change in the text.

Thanks for your review and suggestions.

Brian

> -----Original Message-----
> From: Matt Lepinski [mailto:[email-masked]]
> Sent: Thursday, October 25, 2007 4:03 PM
> To: ECRIT; Brian Rosen; [email-masked]; James M. Polk; [email-masked]
> Subject: draft-ecrit-framework-03 (comments on document content)
> 
> 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