Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices

Note: This ballot was opened for revision 08 and is now closed.

(Richard Barnes) Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Spencer Dawkins) No Objection

Comment (2013-11-20 for -08)
No email
send info
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

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?

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2014-08-14)
No email
send info
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.

(Brian Haberman) No Objection

Comment (2013-11-21 for -08)
No email
send info
Color me supportive of the DISCUSS points raised by Pete and Stephen.

(Joel Jaeggli) No Objection

Comment (2013-11-19 for -08)
No email
send info
   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

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.

Barry Leiba No Objection

Comment (2013-11-15 for -08)
No email
send info
-- 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:

   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).

   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:

   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.

-- 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

Given that 802.11-2012 has bee published:
...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?

(Ted Lemon) No Objection

Comment (2013-11-20 for -08)
No email
send info
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!

(Pete Resnick) (was Discuss) No Objection

Comment (2014-02-25 for -08)
No email
send info
[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

5.1.2.  ESRP Discovery

   The end host MUST discover the ESRP using the LoST protocol
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.

(Martin Stiemerling) No Objection