Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices
draft-ietf-ecrit-unauthenticated-access-10

[Ballot comment]

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.

[Ballot discuss]

I see that this draft is now aiming to be informational,
which helps a lot, thanks.

However, I do not see that any of the authors, chairs
or shepherd have engaged with any of the IESG
comments, nor with this discuss. So I'd like to discuss
that before I figure out which of my discuss points are
really ok being comments. (Apologies in advance if
my scan of my local mail missed something.)

Original discuss text below:

If you resolve Pete's discuss by making this
informational most of my discuss points will become
comments.

(1) section 5.1.1, says you MUST use DHCP all the time
to ever make an unauthorized emergency call (to get
the LoST server address).  That seems wrong. Why can't
a static IP host get an emergency call?  Did the WG
consider this?

(2) Given (1) above and the fact that the note
commented on below implies that this spec is somewhat
speculaive, should this one be experimental and not
standards track?

(3) If the l2 solution from section 6 works, then why
is anything else needed?

(4) Section 6.2 - what is there here that could be
implemented that would give interop? This seems like a
hodge-podge of possible ways of attaching to a
network, none of which are sufficiently detailed here.

[Ballot comment]
[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.

[Ballot comment]
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?

[Ballot comment]
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!

[Ballot discuss]


If you resolve Pete's discuss by making this
informational most of my discuss points will become
comments.

(1) section 5.1.1, says you MUST use DHCP all the time
to ever make an unauthorized emergency call (to get
the LoST server address).  That seems wrong. Why can't
a static IP host get an emergency call?  Did the WG
consider this?

(2) Given (1) above and the fact that the note
commented on below implies that this spec is somewhat
speculaive, should this one be experimental and not
standards track?

(3) If the l2 solution from section 6 works, then why
is anything else needed?

(4) Section 6.2 - what is there here that could be
implemented that would give interop? This seems like a
hodge-podge of possible ways of attaching to a
network, none of which are sufficiently detailed here.

[Ballot comment]


- The note at the end of p4/start of p5 seems odd to
me. I'd say delete it.

- section 6: expand acronyms please, e.g. STA, NAI

[Ballot comment]
  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.

[Ballot discuss]
I don't understand how this document is appropriate for standards track. It strikes me as almost entirely Informational. Sections 1 & 2 are introductory and definitional. Section 3 lays out the use case categories, but doesn't introduce any new protocol. It simply points to sections 4, 5, and 6. Section 4 says that it is only describing the regulatory environment, and section 6 describes itself as non-normative. In fact, it's not clear to me why the discussions in section 4 & 6 are within charter for the WG. The only "normative" text in this document appears in section 5, but it does not appear to me to be normative with regard to protocol. 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 not a proper part of a standards track protocol document, certainly not with "MUST" in front of them. 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, not appropriate for standards track.

But overall, I think this document should be Informational, and the "normative" language should be removed.

[Ballot comment]
-- 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?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ecrit-unauthenticated-access-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.  IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices) to Proposed Standard


The IESG has received a request from the Emergency Context Resolution
with Internet Technologies WG (ecrit) to consider the following document:
- 'Extensions to the Emergency Services Architecture for dealing with
  Unauthenticated and Unauthorized Devices'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IETF emergency services architecture assumes that the calling
  device has acquired rights to use the access network or that no
  authentication is required for the access network, such as for public
  wireless access points.  Subsequent protocol interactions, such as
  obtaining location information, learning the address of the Public
  Safety Answering Point (PSAP) and the emergency call itself are
  largely decoupled from the underlying network access procedures.

  In some cases, however, the device does not have these credentials
  for network access, does not have a VoIP service provider, or the
  credentials have become invalid, e.g., because the user has exhausted
  their prepaid balance or the account has expired.

  This document provides a problem statement, introduces terminology
  and describes an extension for the base IETF emergency services
  architecture to address these scenarios.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ballot/


No IPR declarations have been submitted directly on this I-D.

Technical Summary

The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures.
In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired.
This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios.


Working Group Summary

This document represents strong work group consensus and broad group participation in developing the solution provided. There were no significant controversies that were not overcome during the development stage. A successful document development history is documented in the ecrit email list archive.


Document Quality

No existing implementations are known to exist. Several vendors were involved in sponsoring the document originally, and have stayed involved in the development and review of the document.


Personnel

Document shepherd: Roger Marshall (ECRIT co-chair)
Responsible Area Director: Richard Barnes (RAI AD)


Write-up as follows:


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Detailed review following WGLC. No nits reported.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Not that I'm aware of.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

None noted.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been recorded.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is strong work group consensus to move this document forward to RFC status.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits were reported.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no MIB, media, or new URI types referenced in this document.



(13) Have all references within this document been identified as
either normative or informative?

Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No referenced RFCs will change in status due to publication of this document.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA requirements in this document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.



(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None applied.