Subject: [Ecrit] NENA NG9-1-1 related Standard for review

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 08 Apr 2008 21:32:20 +0300

Folks,

Roger Hixson is asking for feedback on a NENA document (see attachment). 
Who would be willing to review the NENA document? Please drop us a note.

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Richard Barnes <[email-masked]>
Date: Tue, 08 Apr 2008 14:54:33 -0400

I will review the document.
--RB

Hannes Tschofenig wrote:
> ------------------------------------------------------------------------
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 16 Apr 2008 14:53:45 -0400

If other folks are reviewing this document, the version linked from 
Roger's email is broken; some of the figures got destroyed.  There's a 
good version on the NENA web site at the following URI:
<http://www.nena.org/media/files/08-002V120071218.pdf>

--RB

---

From: Richard Barnes <[email-masked]>
Date: Tue, 29 Apr 2008 15:23:54 -0400

Document: Functional and Interface Standards for Next Generation 9-1-1 
Version 1.0 (i3)
Reviewer: Richard L. Barnes
Date: 29 April, 2008

I have reviewed Sections 1, 2, 3, 4, 5.1, 5.2, 6, 7, 8, and 9 of this 
document.  It is basically technically sound, in that the architecture 
it describes seems to meet the functional requirements of the NG9-1-1 
system.  My major reservation is that the security requirements and 
properties of this system are largely undefined and highly reliant on 
perimeter defenses.  Specific comments follow.

Major technical comments:

General:
It is unclear in what manner ESInets are connected to each other, i.e., 
at what layer they are peered.  Is it intended that they be physically 
connected (physical/link layer)?  That they be connected at the IP layer 
(e.g., over a tunnel or VPN)?  Or that they exchange messages over 
public IP networks?  These choices have very different security 
implications, so even if a single scheme is not chosen, there should be 
a discussion of trade-offs.  Section 4.2.5.3 says that they are 
connected at the “IP (router) level”, but even then, it’s not clear 
whether the routers have to be physically connected or whether they can 
have an IP network in between them.

General:
It’s not clear what value the SOA sections (Section 4.6 and Section 6) 
add to this document, since it seems like they are simply a recitation 
of the Web Services canon.  If the point is simply to say that web 
service and corresponding discovery systems will be offered over the 
ESInet, then that’s what should be said.  Note also that several of the 
services described in Section 7 are not web services, e.g., the agency 
registry (Section 7.6) is an LDAP service.

General:
Section 9 needs to be substantially reduced or eliminated.  Without a 
model for what security guarantees the system is to provide and how it 
is to provide them (presumably the eventual contents of Section 4.7), 
the list of technologies in Section 9 is useless.  Moreover, by 
presenting them without context, there is a risk that entities will 
claim compliance with the “i3 security model” without actually providing 
the necessary security properties.

Lines 768-733 (Section 4.2.1, paragraph starting “While other standard 
bodies…”)
This distinction between the IETF and the 3GPP[2] is unnecessary.  The 
suite of protocols defined by the IETF is equally well suited to 
proxy-based routing as to endpoint-based routing.  Indeed, the IMS 
architecture is based on these protocols.  What should be here is a 
discussion of the separation between AIP and CSP, which leads to a 
requirement for the endpoint to be delivered location in certain 
circumstances.

Line 1147 (Section 4.3.3, paragraph starting “The user initiates…”)
This paragraph says that the UE “evaluates the SIP URI” to recognize an 
emergency call.  What does this examination entail?  Suggest changing 
“SIP URI” or “Service URN”.

Line 1504 (Section 4.7)
This section should at least define what it means by “Security Domain” 
in figure 4-19, e.g., by choosing one of the eight definitions in RFC 
4949.  Any commentary on what security services are available within and 
between domains would be helpful, as well as on the implications of 
these choices.

Line 1576 (Section 5.1.1)
This section essentially specifies that BCFs will act as 
application-layer gateways (ALGs) for SIP traffic.  Experience in the 
SIP community has shown that ALGs tend to reduce the reliability of call 
establishment through them, so there is a risk that the use of BCFs in 
this way could add brittleness to the ESInet.  Note also that if the BCF 
does not act as a back-to-back user agent (B2BUA), then BCF manipulation 
of firewall rules is pointless, since media traffic will likely not pass 
back through this BCF.

Line 2423 (Section 7.4)
Why is this service associated with the ECRF, instead of a location 
function (LIS/LRF/LDF), or possibly a third party service (via UDDI)? 
The point of delivery for this service should be left unspecified, as it 
is for most other services here.

Minor technical comments:

Line 515 (Paragraph starting “Calls will be multimedia…”)
It should be clarified that the list of media types here is not 
exhaustive; i.e., other media types might be added in the future.

Line 522 (Section 4.1.2 Functional architecture)
Location functions (LRF/LDF/LAF) are missing from this diagram.  Should 
they be illustrated in the access network?

Line 577 (Location Validation Function)
This bullet should make it clear that the MSAG is not present in this 
architecture, and that the reference to it here is only for purposes of 
analogy.  (This is essentially what’s in the footnote, but this is an 
important point.)

Line 670 (Section 4.1.4, paragraph starting “This example physical 
architecture…”)
It would be helpful here to have a brief statement of how an ESNet 
differs from an ESInet

Line 808 (Section 4.2.1.1)
The reference to the Revised Civic document should be to RFC 5139.

Lines 1094-1097 (Section 4.3.2)
E-CSCF: I was under the impression that the E-CSCF was intended to be 
part of the access network (as opposed to part of the ESInet.
S-CSCF: This term has not been defined in this section.
I would have thought that the ESRP would behave like an I-CSCF, in that 
it is a public-facing CSCF.

Line 1144 (Figure 5-3)
The IP-CAN line in this figure should be deleted.  It’s confusing that 
only some of the lines where location is sent are so labeled; it should 
be added where not present.

Lines 1352, 1356 (Section 4.5.2, paragraph starting “The LIS is 
responsible…”)
The term “Phase II” has not been defined in this document.

Lines 2435, 2449 (Section 7.6, 7.7)
These sections use the all-caps words “MUST”.  Is this word intended to 
be used as in RFC 2119?  If not, please change to lower/mixed caps; if 
so, please include a reference to RFC 2119.

Line 2654 (Section 9, first paragraph)
Capitalization of “IPSEC” should be “IPsec”.

Editorial comments:

Line 333 (Table of acronyms):
In the definitions for 3GPP and 3GPP2, there’s a discrepancy between 3rd 
and 3RD.
IETF working group names (e.g., ECRIT, GEOPRIV) should be capitalized.
“IPSec” should be capitalized as “IPsec”.

Line 731 (Incident Identifier)
The phrase “URI GUID” is incorrect.  It seems to me that it should 
simply be a “GUID”, but if it’s a URI encoding a GUID, then the correct 
phrase is “GUID URI”.

Line 808 (Section 4.2.1.1)
The hyphen in “RFC-4119” should be deleted.

Line 815 (Section 4.2.1.2, paragraph starting “The construction…”)
The phrase “user part” should be deleted, since this term is not defined 
for many URI types.