Telechat Review of draft-ietf-ecrit-unauthenticated-access-08
review-ietf-ecrit-unauthenticated-access-08-secdir-telechat-tsou-2013-11-04-00

Dear all,

Some other nits:

* Section 1, page 2:

to PSAP URI by offering LoST [RFC5222] services.

Please expand the acronymns.

* Section 1, page 4:

  help may find himself/herself in, for example, a NAA and NASP

  situation, as explained in more details in Figure 1.

s/details/detail/?

* Section 1, page 4:

We discuss each case in more details in Section 3.

s/detail/details/

* Section 5, page 8:

As an initial step the devices attaches to the network as shown in

     step (1).

* Section 5, page 8:

  o  When the link layer network attachment procedure is completed the

     end host learns basic IP configuration information using DHCP from

     the ISP, as shown in step (2).

Does this assume IPv4? (DHCPv6 is not mandatory for IPv6.)

* Section 5.1.3, page 10:

The description in Section 6.5 and 6.6

  of [RFC6881] regarding the interaction between the device and the LIS

  applies to this document.

s/6.6/Section 6.6/ -- this e.g. allows the html version of this document

to contain an hyperlink to the corresponding section of such RFC.

Section 6.1, page 13:

  o  Dependency on the specific access network architecture.  Access

     authorization and policy decisions typically happen at a different

     layers of the protocol stack and in different entities than those

     terminating the link-layer signaling.

s/different layers/different layer/

Thank you,

Tina

On Sep 27, 2013, at 3:57 PM, "Tina TSOU" <

Tina.Tsou.Zouting at huawei.com

> wrote:

Dear all,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document
 editors and WG chairs should treat these comments just like any other last
 call comments.



Draft-ietf-ecrit-unauthenticated-access-07 provides extensions to the emergency
services architecture described in other documents to allow emergency services
calling to proceed even when the caller is unauthenticated and unauthorized.
 The draft is particularly relevant to mobile devices, where such a situation
 is most likely to arise. It assumes separate entities provide network access
 and process calls at the application level, and based on that, deals with
 three cases, not necessarily mutually exclusive:

   -- no access authentication;

   -- no application service provider reachable;

   -- subscribed application service provider reachable but ordinary

      service denied because of zero credit balance or other reasons.

Full understanding of this document required review of RFC 5069 (security
requirements specifically for emergency call marking and mapping), RFC 6443,
the emergency calling framework, and RFC 6881, a BCP specifying requirements
for various
 components of the emergency calling system beginning with the subscriber
 device.



The draft states that it is forward-looking, and is input for other SDOs. One
example of this is the reliance on DHCP provisioning, which is at this point
little-implemented in cellular devices.



General remark: the document is very heavy on abbreviations, which makes
serious demands on the novice reader at some points. The terminology and
abbreviations are introduced quite properly at the beginning of the document,
but the authors
 might still ease the reader's task by spelling out at least the less-used
 abbreviations either whenever used (if only two or three times) or perhaps
 once per section.



General assessment: The document is basically ready, but lacks a statement of
the specific points in RFCs 6443 and 6881 that need to be changed due to lack
of authentication or authorization. As a result, the NASP and NAA sections are
unmotivated.



Editorial: Section 7 in a few places does not quite seem to say what I think it
means, hence the following suggestions:



Suggestion, sec. 7, fourth para, first sentence:

Currently: "We only illustrate a possible model."

Suggested: "We illustrate just one possible model for obtaining the destination
addresses to which emergency callers should be restricted in the NAA case."



In the next sentence, missing some words: "... as well

    as the address of the LoST server itself."

       ^^^^^^^^^^^^^^



Suggestion, sec. 7, fifth para, first sentence:

Currently: "For the ZBP case the additional aspect of fraud has to be
considered."

Suggested: "The additional aspect of fraud also has to be considered for the
ZBP case."





Typos:



Typo, sec. 5, first bullet: devices -> device



Typo, sec. 7, second para, last sentence: lead -> led



Typo, sec. 7, third para, fourth line: fraudulent -> fraudulently



Thank you,

Tina