Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices
draft-ietf-ecrit-unauthenticated-access-10
Yes
(Richard Barnes)
No Objection
(Adrian Farrel)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Stewart Bryant)
Note: This ballot was opened for revision 08 and is now closed.
Richard Barnes Former IESG member
Yes
Yes
(for -08)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -08)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2013-11-15 for -08)
Unknown
-- Abstract -- With features provided by the Public Switched Telephone Network (PSTN) there is precedence for some of these use cases That should be "precedent", not "precedence". -- Section 1 -- New devices and services are being made available that could be used to make a request for help, which are not traditional telephones, and users are increasingly expecting them to be used to place emergency calls. That's awkward. Making it, "those devices are not traditional telephones" will fix it. divides responsibility for handling emergency calls between the access network (ISP), the application service provider (ASP) that may be a VoIP service provider (VSP) and the provider of emergency signaling services, the emergency service network (ESN). Also awkward. I can't figure out how many items are in the list, nor where they're divided. I *think* you want this: NEW divides responsibility for handling emergency calls among the access network (ISP); the application service provider (ASP), which may be a VoIP service provider (VSP); and the provider of emergency signaling services, the emergency service network (ESN). END We distinguish between three conditions: Total nit: Between two, but "among" three or more. These three cases are not mutually exclusive. A caller in need for help may find himself/herself in, for example, a NAA and NASP situation, as explained in more details in Figure 1. Total nit: "himself/herself" is really awkward, and, oh, so unnecessary. Try: NEW These three cases are not mutually exclusive. A caller in need of help may, for example, be in a NAA and NASP situation, as explained in more detail in Figure 1. END -- Section 3 -- On a very high-level, the steps to be performed by an end host not being attached to the network and the user starting to make an Does "not being attached" mean "that is not attached"? If so, please change it, for better English. -- Section 6 -- since the relationship to the IETF emergency is only indirect, namely via some protocols developed within the IETF (e.g., EAP and EAP methods) that require extensions to support this functionality. "to the IETF emergency"? Something missing here (maybe "services architecture")? -- Section 6.2 -- The details are incorporated into the not yet published 802.11-2011 specification. Given that 802.11-2012 has bee published: http://standards.ieee.org/findstds/standard/802.11-2012.html ...I'm skeptical of this statement. Care to amend it? In one case (e.g., WiMAX) an EAP method is performed. However, no credentials specific to either the server or the device or subscription are used as part of the authentication exchange. An example for this would be an EAP-TLS exchange with using the TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly available static key for emergency access could be used. In the latter case, the device would need to be provisioned with the appropriate emergency key for the IAP/ISP in advance. In another case (e.g., IEEE 802.11), no EAP method is used, so that empty frames are transported during the over the air IEEE 802.1X exchange. In this case the authentication state machine completes with no cryptographic keys being exchanged. The "in one case, e.g." and "in another case, e.g." stuff reads very oddly. Further, the whole paraagraph seems raambling and not fully connected. I'm not really cleaar about what you're trying to say. Please re-word this. at least the device identity (e.g., the MAC address) can be authenticated Again, I wonder about the "e.g.": either you mean that the MAC address *is* what identifies the device, in which case you should just drop the "e.g.,", or you mean that the MAC address is one way to determine the device identity, in which case you should word it differently, perhaps as, "at least the device identity (determined by a mechanism such as the MAC address) can be authenticated". As it's written, it's not at all clear which you mean. -- Section 7 -- If the ISP runs its own LoST server, it would maintain an access control list including all IP addresses contained in responses returned by the LoST server, as well as the LoST server itself. (It may need to translate the domain names returned to IP addresses and hope that the resolution captures all possible DNS responses.) What is "it" in the parentheses? The ISP? The LoST server? The access control list? Please replace "it" with something specific. Finally, a number of security vulnerabilities discussed in [RFC6280] around faked location information are less problematic in the context of unauthenticated emergency since location information does not need to be provided by the end host itself or it can be verified to fall within a specific geographical area. I'm having trouble understanding the point here, perhaps because of the long, run-on sentence. Can you try re-wording this, please?
Brian Haberman Former IESG member
No Objection
No Objection
(2013-11-21 for -08)
Unknown
Color me supportive of the DISCUSS points raised by Pete and Stephen.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -08)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -08)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2013-11-19 for -08)
Unknown
5.2.2. Location Determination and Location Configuration The ISP is responsible for location determination and exposes this information to the end points via location configuration protocols. The considerations described in [RFC6444] are applicable to this document. This assumes a level of coordination which might exist, but may not. there's a significant level of un-coordination here if you in fact cannot expose this.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -08)
Unknown
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(2014-02-25 for -08)
Unknown
[Clearing my DISCUSS, since the document has been moved to Informational, but leaving in my comments, if you wish to address them.] - It's not clear to me why the discussions in section 4 & 6 are within charter for the WG. - The "normative" text in this document appears in section 5, but I am not convinced it's appropriate. For example: 5.1.1. LoST Server Discovery The end host MUST discover a LoST server [RFC5222] using DHCP [RFC5223]. 5.1.2. ESRP Discovery The end host MUST discover the ESRP using the LoST protocol [RFC5222]. As far as I know, both of those are technically not true. An end host could just as easily have a pre-configured LoST server for these purposes, or might discover the ESRP out of band. There is no protocol requirement for these steps. There *may* be a policy/regulatory reason to perform those steps, but that's an odd use of "MUST". If the claim is that a host MUST do these things in order to be compliant with 6881, that's also not a proper use of "MUST", and is not a protocol requirement. In it's strongest interpretation, this section is all operational guidance. I think the "normative" language should be removed.
Spencer Dawkins Former IESG member
No Objection
No Objection
(2013-11-20 for -08)
Unknown
I would be OK publishing this doc as Informational, if that's where Pete's discussion ends up. I'm not wild about publishing an emergency services spec as Experimental unless we think there's an actual experiment happening someplace. I have a couple of questions I'd appreciate help with. In this text: 5.1.4. Emergency Call Identification To determine which calls are emergency calls, some entity needs to map a user entered dialstring into this URN scheme. A user may "dial" 1-1-2, 9-1-1, etc., but the call would be sent to urn:service:sos. This mapping SHOULD be performed at the endpoint device. could you help me understand why a SHOULD is appropriate? Is there a good reason a conformant implementation wouldn't do that, or is this text trying to accommodate legacy implementations that don't do the mapping now? I may be more confused than usual because I'm not sure whether this text means "[SHOULD be performed] at the endpoint", or "SHOULD be [performed at the endpoint] if it's performed at all". In this text: 5.1.5. SIP Emergency Call Signaling Regarding callback behavior SIP UAs SHOULD place a globally routable URI in a Contact: header. is this text specifically asking for the GRUU mechanism defined by RFC 5627, or something broader? If you told me there were good reasons why this is a SHOULD and not a MUST, I'd believe you, but if this really is a SHOULD, giving some examples of why not doing this makes sense would be helpful. Are there good reasons that you wouldn't provide a callback URI, or is the text accommodating legacy gear that doesn't do this now?
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-08-14)
Unknown
Thanks for (eventually:-) discussing my discuss. As I said before this being informational helps. However, there is still a conflict between the tracker which says this is targetting informational and the draft which still stays standards track. I assume the tracker is correct since that's what we discussed so hope an RFC editor note is added to clarify that.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -08)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(2013-11-20 for -08)
Unknown
The abstract is too long to be useful—it's more like an introduction. It's a little late to be correcting that now, but I'd like the authors to consider it. You could probably winnow it down to something like this: This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network. You might need more than the above, but surely you don't need four paragraphs. Of course, if you make a change along these lines, you will need to define some of the terminology now defined in the abstract in the terminology section instead. Introduction, paragraph 2, this sentence doesn't make sense: Roughly speaking, the IETF emergency services architecture (see [RFC6881] and [RFC6443]) divides responsibility for handling emergency calls between the access network (ISP), the application service provider (ASP) that may be a VoIP service provider (VSP) and the provider of emergency signaling services, the emergency service network (ESN). Are you possibly missing an "and" after the last comma? The sentence starts off fine, but I can't tell what the last dependent clauses is trying to do. Section 5, second bullet, it might be worth exploring a bit further how DHCP happens in this case; it's not unusual for an ISP to configure a DHCP server to only communicate with known clients. Also, is this an IPv4-only document, or is this intended to also work for IPv6 networks? If so, shouldn't SLAAC be mentioned as well? Cool stuff, thanks for working on it!