Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices
RFC 7406
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Richard Barnes; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
-- 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 steering group member) No Objection
Color me supportive of the DISCUSS points raised by Pete and Stephen.
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
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 steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss) No Objection
[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 steering group member) No Objection
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 steering group member) (was Discuss) No Objection
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 steering group member) No Objection
(Ted Lemon; former steering group member) No Objection
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!