IEEE “Green Book” This set of slides is a collection of presentations, motions and other material that has come before the Working Group or is about to be proposed to the Working Group (marked as “Proposed”). Adopted material is to be shown with adoption date and vote, e.g. “Adopted 9/15/10 6/0/1”

Contents Definitions Normative references Discussion of rationale and scope Technical areas to be addressed by standard Security considerations

Definitions ES: Emergency Services EUT: “End User Terminal”, the host to the IP application (e.g. VoIP) which places the ES call.

Normative references RFC 3693, GeoPriv Requirements draft-ietf-ecrit-phonebcp-13 ECRIT Req'ts (US) FCC (Korea) TBD IEEE u draft 12.0 IEEE Std n – 200n draft-rosen-ecrit-additional-data draft-schulzrinne-ecrit-psap-callback draft-schulzrinne-ecrit-unauthenticated-access

Discussion of rationale and scope E911 calls (and their other country equivalents) need to provide location information when initiating ES calls. While other sources of location information may be available to the EUT, it is desirable to provide location from the infrastructure (especially fixed infrastructure). This information will be supplied up through the management plane of the EUT. The EUT will, in turn transmit this data within an IP transaction across the 802 network to the first L2/L3 encountered away from the EUT. At that point the data transaction exits the 802 scope and domain.

Technical areas to be addressed by standard (1/3) LocationStatus: Certain We expect this to be our main task. We intend to supply formatted (infrastucture based) location information to the call originating EUT for it to include in the IP ES call initiation procedure. CallbackStatus: Uncertain for 802 We don't believe that the L1/L2 network has any task to perform to support Callback within the bounds of the EUT remaining within the same bridged 802 network.

Technical areas to be addressed by standard (2/3) Unauthorized Access (1/2) This is a contentious feature within the IETF and ECRIT as it would (according to them) require a “business relationship” between the “Access Provider” (i.e. the provider of simple connectivity to the Internet) and the “Service Provider” (i.e. the application provider, e.g. the provider of VoIP “service”) Unclear whether IETF will support this service. Unclear which markets (if any) will require this by regulation for the space where APP prov & SERV prov are truly separate

Technical areas to be addressed by standard (3/3) Unauthorized Access (2/2) “Authorization” in this context can take place in the 802 L1/L2 Level (e.g X Port Authentication) - OR - In the IETF Level above the 802 Layer (e.g. denial of granting IP address, no subscription to a VoIP service). Providing unauthorized access would add significant complexity at the L1/L2 Level (dedicated EtherType & VLAN?) and at the IETF Level (access providers would have to provide a default VoIP service?) STATUS: Uncertain to unlikely.

Security Considerations Authorized Access We assume that the ordinary security associated with the subscribed VoIP service is adequate security for the over the air portion of an 802 wireless connection (or other 802 connection). We assume that the actual location of Wireless APs & equivalents is not something that needs to be held as secure data. Unauthorized Access In the unauthorized case, we need to be able to access a secured LAN in the event (only) of an Emergency Call (How?). In the above case the call should be restricted to PSAP service only as a destination. Such a call should be provided with security as good or better than a normal VoIP call.