Data-Only Emergency Calls
draft-ietf-ecrit-data-only-ea-12

Internet-Draft          Data-Only Emergency Calls              July 2016

          <presence
             xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gbp=
                    "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
             xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
             xmlns:gml="http://www.opengis.net/gml"
             xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
             entity="pres:alice@atlanta.example.com">
           <dm:device id="sensor">
             <gp:geopriv>
               <gp:location-info>
                 <gml:location>
                   <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                     <gml:pos>32.86726 -97.16054</gml:pos>
                   </gml:Point>
                </gml:location>
               </gp:location-info>
               <gp:usage-rules>
                 <gbp:retransmission-allowed>false
                 </gbp:retransmission-allowed>
                 <gbp:retention-expiry>2010-11-14T20:00:00Z
                 </gbp:retention-expiry>
               </gp:usage-rules>
               <gp:method>802.11</gp:method>
             </gp:geopriv>
             <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
           </dm:device>
         </presence>
      --boundary1--

       Figure 3: Example Message conveying an Alert to an aggregator

   This shows the same CAP document sent as a data-only emergency call
   towards a PSAP.

      MESSAGE urn:service:sos SIP/2.0
      Via: SIP/2.0/TCP sip:aggreg.1.example.com;branch=z9hG4bK776abssa
      Max-Forwards: 70
      From: sip:aggregator@example.com;tag=32336
      To: 112
      Call-ID: asdf33443a@example.com
      Route: sip:psap1.example.gov
      Geolocation: <cid:abcdef@example.com>
        ;routing-allowed=yes
      Supported: geolocation
      Accept: application/pidf+xml,application/EmergencyCallData.cap+xml

Rosen, et al.           Expires January 19, 2017               [Page 13]
Internet-Draft          Data-Only Emergency Calls              July 2016

      Call-info: cid:abcdef2@domain.com;purpose=EmergencyCallData.cap
      CSeq: 1 MESSAGE
      Content-Type: multipart/mixed; boundary=boundary1
      Content-Length: ...

      --boundary1

      Content-Type: application/EmergencyCallData.cap+xml
      Content-ID: <abcdef2@example.com>
     <?xml version="1.0" encoding="UTF-8"?>

     <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
       <identifier>S-1</identifier>
       <sender>sip:sensor1@domain.com</sender>
       <sent>2008-11-19T14:57:00-07:00</sent>
       <status>Actual</status>
       <msgType>Alert</msgType>
       <scope>Private</scope>
       <incidents>abc1234</incidents>
       <info>
           <category>Security</category>
           <event>BURGLARY</event>
           <urgency>Expected</urgency>
           <certainty>Likely</certainty>
           <severity>Moderate</severity>
           <senderName>SENSOR 1</senderName>
           <parameter>
             <valueName>SENSOR-DATA-NAMESPACE1</valueName>
             <value>123</value>
           </parameter>
           <parameter>
             <valueName>SENSOR-DATA-NAMESPACE2</valueName>
             <value>TRUE</value>
           </parameter>
       </info>
      </alert>

      --boundary1

      Content-Type: application/pidf+xml
      Content-ID: <abcdef2@domain.com>
      <?xml version="1.0" encoding="UTF-8"?>
          <presence
             xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:gbp=
                    "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
             xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"

Rosen, et al.           Expires January 19, 2017               [Page 14]
Internet-Draft          Data-Only Emergency Calls              July 2016

             xmlns:gml="http://www.opengis.net/gml"
             xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
             entity="pres:alice@atlanta.example.com">
           <dm:device id="sensor">
             <gp:geopriv>
               <gp:location-info>
                 <gml:location>
                   <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                     <gml:pos>32.86726 -97.16054</gml:pos>
                   </gml:Point>
                </gml:location>
               </gp:location-info>
               <gp:usage-rules>
                 <gbp:retransmission-allowed>false
                 </gbp:retransmission-allowed>
                 <gbp:retention-expiry>2010-11-14T20:00:00Z
                 </gbp:retention-expiry>
               </gp:usage-rules>
               <gp:method>802.11</gp:method>
             </gp:geopriv>
             <dm:timestamp>2010-11-04T20:57:29Z</dm:timestamp>
           </dm:device>
         </presence>
      --boundary1--

          Figure 4: Example Message conveying an Alert to a PSAP

9.  Security Considerations

   This section discusses security considerations when SIP user agents
   issue emergency alerts utilizing MESSAGE and CAP.  Location specific
   threats are not unique to this document and are discussed in
   [RFC7378] and [RFC6442].

   The ECRIT emergency services architecture [RFC6443] considers classic
   individual-to-authority emergency calling where the identity of the
   emergency caller does not play a role at the time of the call
   establishment itself, i.e., a response to the emergency call does not
   depend on the identity of the caller.  In the case of emergency
   alerts generated by devices such as sensors, the processing may be
   different in order to reduce the number of falsely generated
   emergency alerts.  Alerts may get triggered based on certain sensor
   input that may have been caused by factors other than the actual
   occurrence of an alert relevant event.  For example, a sensor may
   simply be malfunctioning.  For this reason, not all alert messages
   are directly sent to a PSAP, but rather may be pre-processed by a
   separate entity, potentially under supervision by a human, to filter

Rosen, et al.           Expires January 19, 2017               [Page 15]
Internet-Draft          Data-Only Emergency Calls              July 2016

   alerts and potentially correlate received alerts with others to
   obtain a larger picture of the ongoing situation.

   In any case, for alerts initiated by sensors, the identity may play
   an important role in deciding whether to accept or ignore an incoming
   alert message.  With the scenario shown in Figure 1 it is very likely
   that only authorized sensor input will be processed.  For this
   reason, it needs to be possible to refuse to accept alert messages
   from an unknown origin.  Two types of information elements can be
   used for this purpose:

   1.  SIP itself provides security mechanisms that allow the
       verification of the originator's identity.  These mechanisms can
       be re-used, such as P-Asserted-Identity [RFC3325] or SIP Identity
       [RFC4474].  The latter provides a cryptographic assurance while
       the former relies on a chain of trust model.

   2.  CAP provides additional security mechanisms and the ability to
       carry further information about the sender's identity.
       Section 3.3.2.1 of [cap] specifies the signing algorithms of CAP
       documents.

   In addition to the desire to perform identity-based access control,
   the classic communication security threats need to be considered,
   including integrity protection to prevent forgery or replay of alert
   messages in transit.  To deal with replay of alerts, a CAP document
   contains the mandatory <identifier>, <sender>, <sent> elements and an
   optional <expire> element.  Together, these elements make the CAP
   document unique for a specific sender and provide time restrictions.
   An entity that has already received a CAP message within the
   indicated timeframe is able to detect a replayed message and, if the
   content of that message is unchanged, then no additional security
   vulnerability is created.  Additionally, it is RECOMMENDED to make
   use of SIP security mechanisms, such as SIP Identity [RFC4474], to
   tie the CAP message to the SIP message.  To provide protection of the
   entire SIP message exchange between neighboring SIP entities, the
   usage of TLS is MANDATORY.

   Note that none of the security mechanism in this document protect
   against a compromised sensor sending crafted alerts.

10.  IANA Considerations

Rosen, et al.           Expires January 19, 2017               [Page 16]
Internet-Draft          Data-Only Emergency Calls              July 2016

10.1.  Registration of the 'application/EmergencyCallData.cap+xml' MIME
       type

   To:  ietf-types@iana.org

   Subject:  Registration of MIME media type application/
      EmergencyCallData.cap+xml

   MIME media type name:  application

   MIME subtype name:  cap+xml

   Required parameters:  (none)

   Optional parameters:  charset; Indicates the character encoding of
      enclosed XML.  Default is UTF-8 [RFC3629].

   Encoding considerations:  Uses XML, which can employ 8-bit
      characters, depending on the character encoding used.  See RFC
      3023 [RFC3023], Section 3.2.

   Security considerations:  This content type is designed to carry
      payloads of the Common Alerting Protocol (CAP).  RFC XXX [Replace
      by the RFC number of this specification] discusses security
      considerations for this.

   Interoperability considerations:  This content type provides a way to
      convey CAP payloads.

   Published specification:  RFC XXX [Replace by the RFC number of this
      specification].

   Applications which use this media type:  Applications that convey
      alerts and warnings according to the CAP standard.

Rosen, et al.           Expires January 19, 2017               [Page 17]
Internet-Draft          Data-Only Emergency Calls              July 2016

   Additional information:  OASIS has published the Common Alerting
      Protocol at http://www.oasis-open.org/committees/
      documents.php&wg_abbrev=emergency

   Person and email address to contact for further information:  Hannes
      Tschofenig, hannes.tschofenig@gmx.net

   Intended usage:  Limited use

   Author/Change controller:  IETF ECRIT working group

   Other information:  This media type is a specialization of
      application/xml RFC 3023 [RFC3023], and many of the considerations
      described there also apply to application/cap+xml.

10.2.  IANA Registration of 'cap' Additional Data Block

   This document registers a new block type in the sub-registry called
   'Emergency Call Data Types' of the Emergency Call Additional Data
   Registry defined in [I-D.ietf-ecrit-additional-data].  The token is
   "cap", the Data About is "The Call" and the reference is this
   document.

10.3.  IANA Registration for 425 Response Code

   In the SIP Response Codes registry, the following is added

   Reference: RFC-XXXX (i.e., this document)

   Response code: 425 (recommended number to assign)

   Default reason phrase: Bad Alert Message

      Registry:
        Response Code                               Reference
        ------------------------------------------  ---------
        Request Failure 4xx
          425 Bad Alert Message                   [this doc]

   This SIP Response code is defined in Section 5.

Rosen, et al.           Expires January 19, 2017               [Page 18]
Internet-Draft          Data-Only Emergency Calls              July 2016

10.4.  IANA Registration of New AlertMsg-Error Header Field

   The SIP AlertMsg-error header field is created by this document, with
   its definition and rules in Section 5, to be added to the IANA
   Session Initiation Protocol (SIP) Parameters registry with two
   actions:

   1.  Update the Header Fields registry with

      Registry:
        Header Name        compact    Reference
        -----------------  -------    ---------
        AlertMsg-Error             [this doc]

   2.  In the portion titled "Header Field Parameters and Parameter
       Values", add

                                               Predefined
      Header Field        Parameter Name       Values      Reference
      -----------------   -------------------  ----------  ---------
      AlertMsg-Error      code                 yes         [this doc]

10.5.  IANA Registration for the SIP AlertMsg-Error Codes

   This document creates a new registry for SIP, called "AlertMsg-Error
   Codes".  AlertMsg-Error codes provide reasons for an error discovered
   by a recipient, categorized by the action to be taken by the error
   recipient.  The initial values for this registry are shown below.

   Registry Name: AlertMsg-Error Codes

   Reference: [this doc]

   Registration Procedures: Specification Required

Rosen, et al.           Expires January 19, 2017               [Page 19]
Internet-Draft          Data-Only Emergency Calls              July 2016

   Code Default Reason Phrase                                 Reference
   ---- ---------------------------------------------------   ---------
   100  "Cannot Process the Alert Payload"                    [this doc]

   101  "Alert Payload was not present or could not be found" [this doc]

   102  "Not enough information to determine
         the purpose of the alert"                            [this doc]

   103  "Alert Payload was corrupted"                         [this doc]

   Details of these error codes are in Section 5.

11.  Acknowledgments

   The authors would like to thank the participants of the Early Warning
   adhoc meeting at IETF#69 for their feedback.  Additionally, we would
   like to thank the members of the NENA Long Term Direction Working
   Group for their feedback.

   Additionally, we would like to thank Martin Thomson, James
   Winterbottom, Shida Schubert, Bernard Aboba, and Marc Linsner for
   their review comments.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [cap]      Jones, E. and A. Botterell, "Common Alerting Protocol v.
              1.1", October 2005.

   [RFC2392]  Levinson, E., "Content-ID and Message-ID Uniform Resource
              Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
              <http://www.rfc-editor.org/info/rfc2392>.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <http://www.rfc-editor.org/info/rfc3261>.

Rosen, et al.           Expires January 19, 2017               [Page 20]
Internet-Draft          Data-Only Emergency Calls              July 2016

   [RFC3428]  Campbell, B., Ed., Rosenberg, J., Schulzrinne, H.,
              Huitema, C., and D. Gurle, "Session Initiation Protocol
              (SIP) Extension for Instant Messaging", RFC 3428,
              DOI 10.17487/RFC3428, December 2002,
              <http://www.rfc-editor.org/info/rfc3428>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, DOI 10.17487/RFC3023, January 2001,
              <http://www.rfc-editor.org/info/rfc3023>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <http://www.rfc-editor.org/info/rfc3629>.

   [RFC6442]  Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
              for the Session Initiation Protocol", RFC 6442,
              DOI 10.17487/RFC6442, December 2011,
              <http://www.rfc-editor.org/info/rfc6442>.

   [RFC6881]  Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in Support of Emergency Calling",
              BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013,
              <http://www.rfc-editor.org/info/rfc6881>.

   [I-D.ietf-ecrit-additional-data]
              Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and
              J. Winterbottom, "Additional Data Related to an Emergency
              Call", draft-ietf-ecrit-additional-data-38 (work in
              progress), April 2016.

12.2.  Informative References

   [RFC7378]  Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed.,
              "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378,
              December 2014, <http://www.rfc-editor.org/info/rfc7378>.

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474,
              DOI 10.17487/RFC4474, August 2006,
              <http://www.rfc-editor.org/info/rfc4474>.

Rosen, et al.           Expires January 19, 2017               [Page 21]
Internet-Draft          Data-Only Emergency Calls              July 2016

   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              DOI 10.17487/RFC3325, November 2002,
              <http://www.rfc-editor.org/info/rfc3325>.

   [RFC6443]  Rosen, B., Schulzrinne, H., Polk, J., and A. Newton,
              "Framework for Emergency Calling Using Internet
              Multimedia", RFC 6443, DOI 10.17487/RFC6443, December
              2011, <http://www.rfc-editor.org/info/rfc6443>.

Authors' Addresses

   Brian Rosen
   NeuStar, Inc.
   470 Conrad Dr
   Mars, PA   16046
   US

   Email: br@brianrosen.net

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: +1 212 939 7004
   Email: hgs+ecrit@cs.columbia.edu
   URI:   http://www.cs.columbia.edu

   Hannes Tschofenig
   ARM Limited
   Austria

   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at

   Randall Gellens

   Email: rg+ietf@randy.pensive.org

Rosen, et al.           Expires January 19, 2017               [Page 22]