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

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 03 May 2008 20:53:24 +0300

Hi Roger,

a question from a procedural point of view: How are Richards comments 
handled?

Ciao
Hannes

Richard Barnes wrote:
> 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.

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

---

From: "Roger Hixson" <[email-masked]>
Date: Sun, 4 May 2008 20:05:19 -0400

I had passed them on to the Committee leadership responsible for this
area, for action as needed. They will advise on what actions they took.

I am so used to liaisons never generating responses back to me (usually
the other SDOs respond back to the Committee leader directly and I hear
about it later) that it didn't occur to me to send you guys a `receipt'
for your responses.  Sorry - we do appreciate that you took action on
the liaison and provided commnents back.

Roger Hixson, ENP
NENA Technical Issues Director
NENA - The Voice of 9-1-1
614-442-9110  USA
[email-masked]

Always make new mistakes !

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Saturday, May 03, 2008 1:53 PM
To: Richard Barnes
Cc: [email-masked]; Roger Hixson
Subject: Re: [Ecrit] NENA NG9-1-1 related Standard for review

Hi Roger,

Ciao
Hannes

> are connected at the "IP (router) level", but even then, it's not 
> It's not clear what value the SOA sections (Section 4.6 and Section 6)

> ESInet, then that's what should be said.  Note also that several of 

> claim compliance with the "i3 security model" without actually 
> Lines 768-733 (Section 4.2.1, paragraph starting "While other standard

> bodies...")

> Line 1147 (Section 4.3.3, paragraph starting "The user initiates...")
> This paragraph says that the UE "evaluates the SIP URI" to recognize 
> changing "SIP URI" or "Service URN".
>
> Line 1504 (Section 4.7)
> This section should at least define what it means by "Security Domain"

> Line 515 (Paragraph starting "Calls will be multimedia...")
> 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...")
> The IP-CAN line in this figure should be deleted.  It's confusing that

> Lines 1352, 1356 (Section 4.5.2, paragraph starting "The LIS is 
> responsible...")
> The term "Phase II" has not been defined in this document.
>
> These sections use the all-caps words "MUST".  Is this word intended 

> Capitalization of "IPSEC" should be "IPsec".
>
>
> Editorial comments:
>
> In the definitions for 3GPP and 3GPP2, there's a discrepancy between 
> 3rd and 3RD.
> "IPSec" should be capitalized as "IPsec".
>
> 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".
>
> 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