# drafts

name: draft-ietf-httpbis-zstd-window-size
rev: 03
title: Window Sizing for Zstandard Content Encoding
time: 2024-09-27T16:30:22Z
group_uri: /api/v1/group/group/1718/
expires: 2025-02-24T08:09:44Z
ad: /api/v1/person/person/119822/
shepherd: /api/v1/person/email/mnot@mnot.net/
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.681047+00:00
source: ietf
source_id: 136471
source_url: https://datatracker.ietf.org/doc/draft-ietf-httpbis-zstd-window-size/
doc_status: active
abstract:
  Deployments of Zstandard, or "zstd", can use different window sizes
     to limit memory usage during compression and decompression.  Some
     browsers and user agents limit window sizes to mitigate memory usage
     concerns, causing interoperability issues.  This document updates the
     window size limit in RFC8878 from a recommendation to a requirement
     in HTTP contexts.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/108/", "/api/v1/doc/state/112/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  HTTPBIS                                                     N. Jaju, Ed.
  Internet-Draft                                                    Google
  Updates: 8878 (if approved)                               F. Handte, Ed.
  Intended status: Informational                      Meta Platforms, Inc.
  Expires: 24 February 2025                                 23 August 2024


                Window Sizing for Zstandard Content Encoding
                   draft-ietf-httpbis-zstd-window-size-03

  Abstract

     Deployments of Zstandard, or "zstd", can use different window sizes
     to limit memory usage during compression and decompression.  Some
     browsers and user agents limit window sizes to mitigate memory usage
     concerns, causing interoperability issues.  This document updates the
     window size limit in RFC8878 from a recommendation to a requirement
     in HTTP contexts.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://httpwg.org/
     http-extensions/draft-ietf-httpbis-zstd-window-size.html.  Status
     information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-httpbis-zstd-window-
     size/.

     Discussion of this document takes place on the HTTP Working Group
     mailing list (mailto:ietf-http-wg@w3.org), which is archived at
     https://lists.w3.org/Archives/Public/ietf-http-wg/.

     Source for this draft and an issue tracker can be found at
     https://github.com/httpwg/http-extensions/labels/zstd-window-size.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.






  Jaju & Handte           Expires 24 February 2025                [Page 1]


  Internet-Draft              Zstd Window Size                 August 2024


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 24 February 2025.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Window Size . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
       5.1.  Content Encoding  . . . . . . . . . . . . . . . . . . . .   4
     6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   4
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

  1.  Introduction

     Zstandard, or "zstd", specified in [RFC8878], is a lossless data
     compression mechanism similar to gzip.  When used with HTTP, the
     "zstd" content coding token signals to the decoder that the content
     is Zstandard-compressed.

     An important property of Zstandard-compressed content is its
     Window_Size ([RFC8878], Section 3.1.1.1.2), which describes the
     maximum distance for back-references and therefore how much of the
     content must be kept in memory during decompression.







  Jaju & Handte           Expires 24 February 2025                [Page 2]


  Internet-Draft              Zstd Window Size                 August 2024


     The minimum Window_Size is 1 KB.  The maximum Window_Size is (1<<41)
     + 7*(1<<38) bytes, which is 3.75 TB.  Larger Window_Size values tend
     to improve the compression ratio, but at the cost of increased memory
     usage.

     To protect against unreasonable memory usage, some browsers and user
     agents limit the maximum Window_Size they will handle.  This causes
     failures to decode responses when the content is compressed with a
     larger Window_Size than the recipient allows, leading to decreased
     interoperability.

     [RFC8878], Section 3.1.1.1.2 recommends that decoders support a
     Window_Size of up to 8 MB, and that encoders not generate frames
     using a Window_Size larger than 8 MB.  However, it imposes no
     requirements.

     This document updates [RFC8878] to enforce Window_Size limits on the
     encoder and decoder for the "zstd" HTTP content coding.

  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  3.  Window Size

     To ensure interoperability, when using the "zstd" content coding,
     decoders MUST support a Window_Size of up to and including 8 MB, and
     encoders MUST NOT generate frames requiring a Window_Size larger than
     8 MB (see Section 5.1).

  4.  Security Considerations

     This document introduces no new security considerations beyond those
     discussed in [RFC8878].

     Note that decoders still need to take into account that they can
     receive oversized frames that do not follow the window size limit
     specified in this document and fail decoding when such invalid frames
     are received.

  5.  IANA Considerations






  Jaju & Handte           Expires 24 February 2025                [Page 3]


  Internet-Draft              Zstd Window Size                 August 2024


  5.1.  Content Encoding

     This document updates the entry added in [RFC8878] to the "HTTP
     Content Coding Registry" (https://www.iana.org/assignments/http-
     parameters/http-parameters.xhtml#content-coding) within the
     "Hypertext Transfer Protocol (HTTP) Parameters"
     (https://www.iana.org/assignments/http-parameters/http-
     parameters.xhtml) registry:

     Name:  zstd

     Description:  A stream of bytes compressed using the Zstandard
        protocol with a Window_Size of not more than 8 MB.

     Reference:  This document and [RFC8878]

  6.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8878]  Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
                and the 'application/zstd' Media Type", RFC 8878,
                DOI 10.17487/RFC8878, February 2021,
                <https://www.rfc-editor.org/rfc/rfc8878>.

  Acknowledgments

     Zstandard was developed by Yann Collet.

     The authors would like to thank Yann Collet, Klaus Post, Adam Rice,
     and members of the Web Performance Working Group in the W3C for
     collaborating on the window size issue and helping to formulate a
     solution.  Also, thank you to Nick Terrell for providing feedback
     that went into RFC 8478 and RFC 8878.

  Authors' Addresses








  Jaju & Handte           Expires 24 February 2025                [Page 4]


  Internet-Draft              Zstd Window Size                 August 2024


     Nidhi Jaju (editor)
     Google
     Shibuya Stream, 3 Chome-21-3 Shibuya, Shibuya City, Tokyo
     150-0002
     Japan
     Email: nidhijaju@google.com


     W. Felix P. Handte (editor)
     Meta Platforms, Inc.
     380 W 33rd St
     New York, NY 10001
     United States of America
     Email: felixh@meta.com





































  Jaju & Handte           Expires 24 February 2025                [Page 5]


name: draft-ietf-dnsop-dns-error-reporting
rev: 08
title: DNS Error Reporting
time: 2024-04-26T19:18:13Z
group_uri: /api/v1/group/group/1452/
expires: 2024-09-05T19:46:28Z
ad: /api/v1/person/person/111656/
shepherd: /api/v1/person/email/benno@NLnetLabs.nl/
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.684927+00:00
source: ietf
source_id: 102148
source_url: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
doc_status: active
abstract:
  DNS error reporting is a lightweight reporting mechanism that
     provides the operator of an authoritative server with reports on DNS
     resource records that fail to resolve or validate.  A domain owner or
     DNS hosting organization can use these reports to improve domain
     hosting.  The reports are based on extended DNS errors as described
     in [RFC8914].

     When a domain name fails to resolve or validate due to a
     misconfiguration or an attack, the operator of the authoritative
     server may be unaware of this.  To mitigate this lack of feedback,
     this document describes a method for a validating resolver to
     automatically signal an error to a monitoring agent specified by the
     authoritative server.  The error is encoded in the QNAME, thus the
     very act of sending the query is to report the error.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/108/", "/api/v1/doc/state/154/", "/api/v1/doc/state/115/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  dnsop                                                          R. Arends
  Internet-Draft                                                 M. Larson
  Intended status: Standards Track                                   ICANN
  Expires: 5 September 2024                                   4 March 2024


                            DNS Error Reporting
                  draft-ietf-dnsop-dns-error-reporting-08

  Abstract

     DNS error reporting is a lightweight reporting mechanism that
     provides the operator of an authoritative server with reports on DNS
     resource records that fail to resolve or validate.  A domain owner or
     DNS hosting organization can use these reports to improve domain
     hosting.  The reports are based on extended DNS errors as described
     in [RFC8914].

     When a domain name fails to resolve or validate due to a
     misconfiguration or an attack, the operator of the authoritative
     server may be unaware of this.  To mitigate this lack of feedback,
     this document describes a method for a validating resolver to
     automatically signal an error to a monitoring agent specified by the
     authoritative server.  The error is encoded in the QNAME, thus the
     very act of sending the query is to report the error.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 5 September 2024.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.




  Arends & Larson         Expires 5 September 2024                [Page 1]


  Internet-Draft                   DNS-ER                       March 2024


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  EDNS0 Option Specification  . . . . . . . . . . . . . . . . .   5
     6.  DNS error reporting specification . . . . . . . . . . . . . .   6
       6.1.  Reporting Resolver Specification  . . . . . . . . . . . .   6
         6.1.1.  Constructing the Report Query . . . . . . . . . . . .   6
       6.2.  Authoritative server specification  . . . . . . . . . . .   7
       6.3.  Monitoring agent specification  . . . . . . . . . . . . .   7
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     8.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
       8.1.  Choosing an agent domain  . . . . . . . . . . . . . . . .   8
       8.2.  Managing Caching Optimizations  . . . . . . . . . . . . .   8
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
       11.2.  Informative References . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

  1.  Introduction

     When an authoritative server serves a stale DNSSEC-signed zone, the
     cryptographic signatures over the resource record sets (RRsets) may
     have lapsed.  A validating resolver will fail to validate these
     resource records.

     Similarly, when there is a mismatch between the Delegation Signer
     (DS) records at a parent zone and the key signing key at the child
     zone, a validating resolver will fail to authenticate records in the
     child zone.

     These are two of several failure scenarios that may go unnoticed for
     some time by the operator of a zone.




  Arends & Larson         Expires 5 September 2024                [Page 2]


  Internet-Draft                   DNS-ER                       March 2024


     Today, there is no direct relationship between operators of
     validating resolvers and authoritative servers.  Outages are often
     noticed indirectly by end users, and reported via E-Mail or social
     media (if reported at all).

     When records fail to validate, there is no facility to report this
     failure in an automated way.  If there is any indication that an
     error or warning has happened, it may be buried in log files of the
     resolver or not logged at all.

     This document describes a method that can be used by validating
     resolvers to report DNSSEC validation errors in an automated way.

     It allows an authoritative server to announce a monitoring agent
     where validating resolvers can report issues if those resolvers are
     configured to do so.

     The burden to report a failure falls on the validating resolver.  It
     is important that the effort needed to report failure is low, with
     minimal impact to its main functions.  To accomplish this goal, the
     DNS itself is utilized to report the error.

  2.  Requirements Notation

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  3.  Terminology

     DNS Terminology used in this document is from BCP 219 [RFC8499], with
     these additions:

     Reporting resolver:  In the context of this document, "reporting
        resolver" is used as a shorthand for a validating resolver that
        supports DNS error reporting.

     Report query:  The DNS query used to report an error is called a
        report query.  A report query is for a DNS TXT resource record
        type.  The content of the error report is encoded in the QNAME of
        a DNS request to the monitoring agent.

     Monitoring agent:  An authoritative server that receives and responds
        to report queries.  This facility is indicated by a domain name,
        referred to as the agent domain.




  Arends & Larson         Expires 5 September 2024                [Page 3]


  Internet-Draft                   DNS-ER                       March 2024


     Agent domain:  A domain name which is returned in the DNS Error
        Reporting EDNS0 option that indicates where DNS resolvers can send
        error reports.

  4.  Overview

     An authoritative server indicates support for DNS error reporting by
     including an EDNS0 Report-Channel option with OPTION-CODE [TBD] and
     the agent domain in the response.  The agent domain is a fully
     qualified, uncompressed domain name in DNS wire format.  The
     authoritative server MUST NOT include this option in the response if
     the configured agent domain is empty, or is the null label (which
     would indicate the DNS root).

     The authoritative server includes the EDNS0 Report-Channel option
     unsolicited.  That is, the option is included in a response despite
     the EDNS0 Report-Channel option being absent in the request.

     If the authoritative server has indicated support for DNS error
     reporting and there is an issue that can be reported via extended DNS
     errors, the reporting resolver encodes the error report in the QNAME
     of the report query.  The reporting resolver builds this QNAME by
     concatenating the _er label, the QTYPE, the QNAME that resulted in
     failure, the extended error code (as described in [RFC8914]), the
     label "_er" again, and the agent domain.  See the example in
     Section 4.1.  Note that a regular RCODE is not included because the
     RCODE is not relevant to the extended error code.

     The resulting report query is sent as a standard DNS query for a TXT
     DNS resource record type by the reporting resolver.

     The report query will ultimately arrive at the monitoring agent.  A
     response is returned by the monitoring agent, which in turn can be
     cached by the reporting resolver.  This caching is essential.  It
     dampens the number of report queries sent by a reporting resolver for
     the same problem, that is, once per TTL.  However, certain
     optimizations such as [RFC8020] and [RFC8198] may reduce the number
     of error report queries as well.

     This document gives no guidance on the content of the TXT resource
     record RDATA for this record.

  4.1.  Example

     A query for "broken.test.", type A, is sent by a reporting resolver.






  Arends & Larson         Expires 5 September 2024                [Page 4]


  Internet-Draft                   DNS-ER                       March 2024


     The domain "test." is hosted on a set of authoritative servers.  One
     of these authoritative servers serves a stale version of the "test."
     zone.  This authoritative server has an agent domain configured:
     "a01.agent-domain.example.".

     The authoritative server with the stale "test." zone receives the
     request for "broken.test".  It returns a response that includes the
     EDNS0 Report-Channel option with the domain name "a01.agent-
     domain.example.".

     The reporting resolver is unable to validate the "broken.test" RRset
     for type 1 (an A record), due to an RRSIG record with an expired
     signature.

     The reporting resolver constructs the QNAME
     "_er.1.broken.test.7._er.a01.agent-domain.example." and resolves it.
     This QNAME indicates extended DNS error 7 occurred while trying to
     validate "broken.test." type 1 record.

     When this query is received at the monitoring agent (the operators of
     the authoritative server for a01.agent-domain.example), the agent can
     determine the "test." zone contained an expired signature record
     (extended error 7) for type A for the domain name "broken.test.".
     The monitoring agent can contact the operators of "test." to fix the
     issue.

  5.  EDNS0 Option Specification

     This method uses an EDNS0 [RFC6891] option to indicate the agent
     domain in DNS responses.  The option is structured as follows:

                          1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        OPTION-CODE = TBD      |       OPTION-LENGTH           |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     /                         AGENT DOMAIN                          /
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

     Field definition details:

     OPTION-CODE:  2 octets; an EDNS0 code that is used in an EDNS0 option
        to indicate support for error reporting.  The name for this EDNS0
        option code is Report-Channel.

     OPTION-LENGTH:  2-octets; contains the length of the AGENT DOMAIN
        field in octets.




  Arends & Larson         Expires 5 September 2024                [Page 5]


  Internet-Draft                   DNS-ER                       March 2024


     AGENT DOMAIN:  A fully qualified domain name [RFC8499] in
        uncompressed DNS wire format.

  6.  DNS error reporting specification

     The various errors that a reporting resolver may encounter are listed
     in [RFC8914].  Note that not all listed errors may be supported by
     the reporting resolver.  This document does not specify what is or is
     not an error.

     The DNS class is not specified in the error report.

  6.1.  Reporting Resolver Specification

     Care should be taken when more DNS resolving is needed to resolve the
     error reporting QNAME.  This resolving itself could trigger another
     error reporting to be created.  A maximum expense or depth limit MUST
     be used to prevent cascading errors.

     The EDNS0 Report-Channel option MUST NOT be included in queries.

     The reporting resolver MUST NOT use DNS error reporting if the
     authoritative server returned an empty agent domain field in the
     EDNS0 Report-Channel option.

     For the benefit of the monitoring agent to get more confidence that
     the report is not spoofed, the reporting resolver SHOULD send error
     reports over TCP [RFC7766] or other connection oriented protocols or
     SHOULD use DNS COOKIEs [RFC7873].  This makes it harder to falsify
     the source address.

     A reporting resolver MUST validate responses received from the
     monitoring agent.  There is no special treatment for responses to
     error-reporting queries.  The Security Considerations section
     contains the rationale behind this.

  6.1.1.  Constructing the Report Query

     The QNAME for the report query is constructed by concatenating the
     following elements:

     *  A label containing the string "_er".









  Arends & Larson         Expires 5 September 2024                [Page 6]


  Internet-Draft                   DNS-ER                       March 2024


     *  The QTYPE that was used in the query that resulted in the extended
        DNS error, presented as a decimal value, in a single DNS label.
        If additional QTYPEs were present in the query, such as described
        in [I-D.ietf-dnssd-multi-qtypes], they are represented as unique,
        ordered decimal values separated by a hyphen.  As an example, if
        both QTYPE A and AAAA were present in the query, they are
        presented as the label "1-28".

     *  The list of non-null labels representing the query name which is
        the subject of the DNS error report.

     *  The extended DNS error, presented as a decimal value, in a single
        DNS label.

     *  A label containing the string "_er".

     *  The agent domain.  The agent domain as received in the EDNS0
        Report-Channel option set by the authoritative server.

     If the report query QNAME exceeds 255 octets, it MUST NOT be sent.

     The "_er" labels allow the monitoring agent to differentiate between
     the agent domain and the faulty query name.  When the specified agent
     domain is empty, or a null label (despite being not allowed in this
     specification), the report query will have "_er" as a top-level
     domain as a result and not the original query.  The purpose of the
     first "_er" label is to indicate that a complete report query has
     been received, instead of a shorter report query due to query
     minimization.

  6.2.  Authoritative server specification

     The authoritative server MUST NOT include more than one EDNS0 Report-
     Channel option in a response.

     The authoritative server includes the EDNS0 Report-Channel option
     unsolicited in responses.  There is no requirement that the EDNS0
     Report-Channel option is present in queries.

  6.3.  Monitoring agent specification

     It is RECOMMENDED that the authoritative server for the agent domain
     replies with a positive response (i.e., not NODATA or NXDOMAIN)
     containing a TXT record.

     The monitoring agent SHOULD respond to queries received over UDP that
     have no DNS COOKIE set with a response that has the truncation bit
     (TC bit) set to challenge the resolver to re-query over TCP.



  Arends & Larson         Expires 5 September 2024                [Page 7]


  Internet-Draft                   DNS-ER                       March 2024


  7.  IANA Considerations

     IANA is requested to assign the following DNS EDNS0 option code
     registry:

           Value Name           Status   Reference
           ----- -------------- -------- ---------------
           TBD   Report-Channel Standard [this document]

     IANA is requested to assign the following Underscored and Globally
     Scoped DNS Node Name registry:

           RR Type  _NODE NAME  Reference
           -----    ----------  ---------
           TXT      _er         [this document]

  8.  Operational Considerations

  8.1.  Choosing an agent domain

     It is RECOMMENDED that the agent domain be kept relatively short to
     allow for a longer QNAME in the report query.  The agent domain MUST
     NOT be a subdomain of the domain it is reporting on.  That is, if the
     authoritative server hosts the foo.example domain, then its agent
     domain MUST NOT end in foo.example.

  8.2.  Managing Caching Optimizations

     The reporting resolver may utilize various caching optimizations that
     inhibit subsequent error reporting to the same monitoring agent.

     If the monitoring agent were to respond with NXDOMAIN (name error),
     [RFC8020] states that any name at or below that domain should be
     considered unreachable, and negative caching would prohibit
     subsequent queries for anything at or below that domain for a period
     of time, depending on the negative TTL [RFC2308].

     Since the monitoring agent may not know the contents of all the zones
     for which it acts as a monitoring agent, the monitoring agent MUST
     NOT respond with NXDOMAIN for domains it is monitoring because that
     could inhibit subsequent queries.  One method to avoid NXDOMAIN is to
     use a wildcard domain name [RFC4592] in the zone for the agent
     domain.








  Arends & Larson         Expires 5 September 2024                [Page 8]


  Internet-Draft                   DNS-ER                       March 2024


     When the agent domain is signed, a resolver may use aggressive
     negative caching (described in [RFC8198]).  This optimization makes
     use of NSEC and NSEC3 (without opt-out) records and allows the
     resolver to do the wildcard synthesis.  When this happens, the
     resolver does not send subsequent queries because it will be able to
     synthesize a response from previously cached material.

     A solution is to avoid DNSSEC for the agent domain.  Signing the
     agent domain will incur an additional burden on the reporting
     resolver, as it has to validate the response.  However, this response
     has no utility to the reporting resolver other than dampening the
     query load for error reports.

  9.  Security Considerations

     Use of DNS error reporting may expose local configuration mistakes in
     the reporting resolver, such as stale DNSSEC trust anchors to the
     monitoring agent.

     DNS error reporting SHOULD be done using DNS query name minimization
     [RFC9156] to improve privacy.

     DNS error reporting is done without any authentication between the
     reporting resolver and the authoritative server of the agent domain.

     Resolvers that send error reports SHOULD send these over TCP
     [RFC7766] or SHOULD use DNS COOKIEs [RFC7873].  This makes it hard to
     falsify the source address.  The monitoring agent SHOULD respond to
     queries received over UDP that have no DNS COOKIE set with a response
     that has the truncation bit (TC bit) set to challenge the resolver to
     re-query over TCP.

     Well-known addresses of reporting resolvers can provide a higher
     level of confidence in the error reports, and potentially enable more
     automated processing of these reports.

     Monitoring agents that receive error reports over UDP should consider
     that the source of the reports and the reports itself may be false.

     The method described in this document will cause additional queries
     by the reporting resolver to authoritative servers in order to
     resolve the report query.









  Arends & Larson         Expires 5 September 2024                [Page 9]


  Internet-Draft                   DNS-ER                       March 2024


     This method can be abused by intentionally deploying broken zones
     with agent domains that are delegated to victims.  This is
     particularly effective when DNS requests that trigger error messages
     are sent through open resolvers [RFC8499] or widely distributed
     network monitoring systems that perform distributed queries from
     around the globe.

     An adversary may create massive error report flooding to camouflage
     an attack.

     Though this document gives no guidance on the content of the TXT
     resource record RDATA for this record, if the RDATA content is
     logged, it MUST assume the content can be malicious and take
     appropriate meassures to avoid exploitation.  One such method could
     be to log in hexadecimal.  This would avoid remote code execution
     through logging string attacks such as [CVE-2021-44228].

     The rationale behind mandating DNSSEC validation for responses from a
     reporting agent, even if the agent domain is proposed to remain
     unsigned, is to mitigate the risk of a downgrade attack orchestrated
     by adversaries.  In such an attack, a victim's legitimately signed
     domain could be deceptively advertised as an agent domain by
     malicious actors.  Consequently, if the validating resolver treats it
     as unsigned, it is exposed to potential cache poisoning attacks.  By
     enforcing DNSSEC validation, this vulnerability is preemptively
     addressed.

  10.  Acknowledgements

     This document is based on an idea by Roy Arends and David Conrad.
     The authors would like to thank Peter van Dijk, Stephane Bortzmeyer,
     Shane Kerr, Vladimir Cunat, Paul Hoffman, Philip Homburg, Mark
     Andrews, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay,
     Dick Franks, Ben Schwartz, Yaron Sheffer, Viktor Dukhovni, Wes
     Hardaker, James Gannon, Tim Wicinski, Warren Kumari, Gorry Fairhurst,
     Benno Overeinder, Paul Wouters and Petr Spacek for their
     contributions.

  11.  References

  11.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.





  Arends & Larson         Expires 5 September 2024               [Page 10]


  Internet-Draft                   DNS-ER                       March 2024


     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  11.2.  Informative References

     [CVE-2021-44228]
                Common Vulnerabilities and Exposures, "CVE-2021-44228", 10
                December 2021, <https://cve.mitre.org/cgi-bin/
                cvename.cgi?name=CVE-2021-44228>.

     [I-D.ietf-dnssd-multi-qtypes]
                Bellis, R., "DNS Multiple QTYPEs", Work in Progress,
                Internet-Draft, draft-ietf-dnssd-multi-qtypes-00, 4
                December 2023, <https://datatracker.ietf.org/doc/html/
                draft-ietf-dnssd-multi-qtypes-00>.

     [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
                NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
                <https://www.rfc-editor.org/info/rfc2308>.

     [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
                System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
                <https://www.rfc-editor.org/info/rfc4592>.

     [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
                for DNS (EDNS(0))", STD 75, RFC 6891,
                DOI 10.17487/RFC6891, April 2013,
                <https://www.rfc-editor.org/info/rfc6891>.

     [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
                D. Wessels, "DNS Transport over TCP - Implementation
                Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
                <https://www.rfc-editor.org/info/rfc7766>.

     [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
                Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
                <https://www.rfc-editor.org/info/rfc7873>.

     [RFC8020]  Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is
                Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020,
                November 2016, <https://www.rfc-editor.org/info/rfc8020>.

     [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
                DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
                July 2017, <https://www.rfc-editor.org/info/rfc8198>.





  Arends & Larson         Expires 5 September 2024               [Page 11]


  Internet-Draft                   DNS-ER                       March 2024


     [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
                Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
                January 2019, <https://www.rfc-editor.org/info/rfc8499>.

     [RFC8914]  Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
                Lawrence, "Extended DNS Errors", RFC 8914,
                DOI 10.17487/RFC8914, October 2020,
                <https://www.rfc-editor.org/info/rfc8914>.

     [RFC9156]  Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query
                Name Minimisation to Improve Privacy", RFC 9156,
                DOI 10.17487/RFC9156, November 2021,
                <https://www.rfc-editor.org/info/rfc9156>.

  Authors' Addresses

     Roy Arends
     ICANN
     Email: roy.arends@icann.org


     Matt Larson
     ICANN
     Email: matt.larson@icann.org



























  Arends & Larson         Expires 5 September 2024               [Page 12]


name: draft-herbert-fast
rev: 07
title: Firewall and Service Tickets
time: 2024-04-09T07:05:00Z
group_uri: /api/v1/group/group/1027/
expires: 2024-04-09T20:55:31Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.689614+00:00
source: ietf
source_id: 82141
source_url: https://datatracker.ietf.org/doc/draft-herbert-fast/
doc_status: active
abstract:
  This document describes the Firewalls and Service Tickets (FAST)
     protocol.  This is a generic and extensible protocol for hosts to
     signal network nodes to request services or to gain admission into a
     network.  A ticket is data that accompanies a packet and indicates a
     granted right to traverse a network or a request for network services
     to be applied (in the latter case the ticket serves as a service
     profile).  Applications request tickets from a local agent in their
     network and attach issued tickets to packets.  Firewall tickets are
     issued to grant packets the right to traverse a network; service
     tickets indicate the desired service to be applied to packets.  A
     single ticket may provide both firewall and service ticket
     information and semantics.  Tickets are sent in IPv6 Hop-by-Hop
     options.

full_text:
  Network Working Group                                         T. Herbert
  Internet-Draft                                                   SiPanda
  Intended status: Standards Track                          7 October 2023
  Expires: 9 April 2024


                        Firewall and Service Tickets
                           draft-herbert-fast-07

  Abstract

     This document describes the Firewalls and Service Tickets (FAST)
     protocol.  This is a generic and extensible protocol for hosts to
     signal network nodes to request services or to gain admission into a
     network.  A ticket is data that accompanies a packet and indicates a
     granted right to traverse a network or a request for network services
     to be applied (in the latter case the ticket serves as a service
     profile).  Applications request tickets from a local agent in their
     network and attach issued tickets to packets.  Firewall tickets are
     issued to grant packets the right to traverse a network; service
     tickets indicate the desired service to be applied to packets.  A
     single ticket may provide both firewall and service ticket
     information and semantics.  Tickets are sent in IPv6 Hop-by-Hop
     options.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 9 April 2024.

  Copyright Notice

     Copyright (c) 2023 IETF Trust and the persons identified as the
     document authors.  All rights reserved.





  Herbert                   Expires 9 April 2024                  [Page 1]


  Internet-Draft                    FAST                      October 2023


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Motivation for FAST . . . . . . . . . . . . . . . . . . .   3
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Hop-by-Hop Options as a signal carrier  . . . . . . . . . . .   4
       2.1.  Motivation for using Hop-by-Hop Options . . . . . . . . .   4
       2.2.  Drawbacks of Hop-by-Hop Options . . . . . . . . . . . . .   5
         2.2.1.  Mitigating Hop-by-Hop Options packet drops  . . . . .   5
         2.2.2.  Support in IPv4 . . . . . . . . . . . . . . . . . . .   6
     3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Example communications flow . . . . . . . . . . . . . . .   8
     4.  Protocol format . . . . . . . . . . . . . . . . . . . . . . .  10
       4.1.  Option format . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.  Option types  . . . . . . . . . . . . . . . . . . . . . .  11
       4.3.  Ticket Data format  . . . . . . . . . . . . . . . . . . .  11
     5.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       5.1.  Origin and reflection properties  . . . . . . . . . . . .  12
       5.2.  Origin application processing . . . . . . . . . . . . . .  13
         5.2.1.  Ticket requests . . . . . . . . . . . . . . . . . . .  13
         5.2.2.  Ticket identification . . . . . . . . . . . . . . . .  14
         5.2.3.  Ticket use  . . . . . . . . . . . . . . . . . . . . .  14
         5.2.4.  Ticket agent delegation . . . . . . . . . . . . . . .  14
       5.3.  Origin network processing . . . . . . . . . . . . . . . .  15
       5.4.  Destination host processing . . . . . . . . . . . . . . .  16
       5.5.  Processing reflected tickets  . . . . . . . . . . . . . .  16
         5.5.1.  Network processing  . . . . . . . . . . . . . . . . .  16
         5.5.2.  Host processing . . . . . . . . . . . . . . . . . . .  16
       5.6.  Removing tickets from packets . . . . . . . . . . . . . .  17
         5.6.1.  Methods to remove tickets . . . . . . . . . . . . . .  17
           5.6.1.1.  Overwriting with a null ticket  . . . . . . . . .  17
           5.6.1.2.  Removing Hop-by-Hop Options containing tickets  .  17
         5.6.2.  Removing tickets without loss of functionality  . . .  17
         5.6.3.  Removing tickets with loss of functionality . . . . .  18
     6.  Implementation considerations . . . . . . . . . . . . . . . .  19
       6.1.  Origin applications . . . . . . . . . . . . . . . . . . .  19
       6.2.  Router implementation . . . . . . . . . . . . . . . . . .  20
       6.3.  Ticket reflection . . . . . . . . . . . . . . . . . . . .  20
       6.4.  Security Considerations . . . . . . . . . . . . . . . . .  20



  Herbert                   Expires 9 April 2024                  [Page 2]


  Internet-Draft                    FAST                      October 2023


     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  22
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

  1.  Introduction

     Firewall and Service Tickets (FAST) is a protocol to allow an
     application to signal the network to request admission and services
     for packets.  FAST is the carrier of signals in host to network
     signaling.  The motivation and use cases of host to network signaling
     are discussed in [I-D.herbert-host2netsig].

     A ticket is data that is attached to a packet by a source node and is
     validated and processed by some or all intermediate nodes in a
     network.  Tickets can express a grant for packets to traverse a
     network or have services applied to them.  Tickets can be opaque or
     have a visible structure containing attributes of requested services.
     Tickets may be encrypted and integrity protected to limit visibility
     and prevent abuse.

     An application requests tickets for admission or services from a
     ticket agent in their local network.  The agent issues tickets to the
     application which in turn attaches them to its packets.  In the
     forwarding path, intermediate network nodes may interpret tickets and
     apply requested services on packets.

     Tickets are validated for authenticity by the network and may contain
     an expiration time so that they cannot be easily forged.  Tickets do
     not have a global interpretation, they can only be interpreted in the
     context of the network or limited domain [RFC8799] that issues them.
     In order to apply services to inbound packets for a communication,
     remote peers reflect received tickets in packets they send without
     interpreting them.  Tickets are stateless within the network, however
     they can be used to attain per flow semantics.  Firewall and service
     tickets should be non-transferable and revocable.

     Tickets are coded in IPv6 Hop-by-Hop options.

  1.1.  Motivation for FAST

     The general motivation and use cases for host to network signaling is
     discussed in [I-D.herbert-host2netsig].  The motivation for using
     IPv6 Hop-by-Hop Options as the carrier of host to network signals is
     discussed below.





  Herbert                   Expires 9 April 2024                  [Page 3]


  Internet-Draft                    FAST                      October 2023


  1.2.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].

  2.  Hop-by-Hop Options as a signal carrier

     The carrier of host to network signaling in FAST is IPv6 Hop-by-Hop
     Options [RFC8200].  This section discusses the motivation for using
     Hop-by-Hop Options, the drawbacks of Hop-by-Hop Options, and methods
     to mitigate those drawbacks.

  2.1.  Motivation for using Hop-by-Hop Options

     [I-D.herbert-host2netsig] discusses some alternatives that might be
     considered for the carrier protocol of host to network signaling.
     Compared to the these alternatives, Hop-by-Hop Options has a number
     advantages that motivate the use of Hop-by-Hop Options as the
     ubiquitous carrier of host to network signals:

     *  IPv6 Hop-by-Hop Options are explicitly designed to be a standard
        and extensible protocol for host to network signaling on a per
        packet basis.  Hop-by-Hop options also facilitate network to host
        signaling.

     *  Hop-by-Hop Options are defined as part of an Internet standard STD
        86 [RFC8200].

     *  Hop-by-Hop Options are a network layer protocol and are
        independent of both transport layer and link layer protocols.

     *  Hop-by-Hop Options work with any transport protocol, encrypted
        IPsec tunnels, as well as any other encapsulation protocols in
        IPv6.

     *  Hop-by-Hop Options are variable length to allow rich expression.

     *  Hop-by-Hop Options are stateless.

     *  Hop-by-Hop Options can change between packets of the same flow.

     *  Hop-by-Hop Options are explicitly intended to be processed by
        intermediate nodes in the path of a packet.







  Herbert                   Expires 9 April 2024                  [Page 4]


  Internet-Draft                    FAST                      October 2023


     *  Hop-by-Hop Options are located in headers of a packet as opposed
        to trailers, and the Hop-by-Hop Options header immediately follows
        the IPv6 header at a fixed offset in the packet.  These
        characteristics make Hop-by-Hop Options amenable to efficient
        processing in both software and hardware implementations.

  2.2.  Drawbacks of Hop-by-Hop Options

     Hop-by-Hop Options have two main drawbacks:

     *  Packets containing Hop-by-Hop Options headers may be summarily
        discarded by some network providers as a matter of policy
        [RFC7872],[RFC9098].

     *  Hop-by-Hop Options is an IPv6 specific protocol, there is no
        equivalent protocol in IPv4.

     The sections below describe mitigations for these drawbacks.

  2.2.1.  Mitigating Hop-by-Hop Options packet drops

     The original processing requirements of IPv6 [RFC2460] Hop-by-Hop
     Options required all routers in the path to process the Hop-by-Hop
     Options header and its options.  In response to this requirement,
     some routers deferred processing of Hop-by-Hop Options to the
     software slow path, others ignored them, and still others elected to
     summarily discard all packets containing Hop-by-Hop Options.  A
     related issue was that the number of Hop-by-Hop Options in a packet
     was only limited by the MTU for the packet.  The lack of a limit,
     combined with the requirement that nodes must skip over unknown
     options when the high order bit in the option type isn't set, created
     the opportunity for DOS attacks by sending long lists of unknown Hop-
     by-Hop options.  The net effect of these issues was that deployment
     of Hop-by-Hop Options on the Internet was significantly impeded to
     the point that the current data suggests that packet with Hop-by-Hop
     Options have more than a 99% drop rate [APNIC-EH].

     There is ongoing work to fix, or at least mitigate, the deployability
     problems of Hop-by-Hop options:

     *  [RFC8200] specifies that intermediate nodes MAY ignore Hop-by-Hop
        options.  There is no concept of a Hop-by-Hop option that must be
        processed by all nodes, and the current assumption in defining any
        new option is that it may be processed by only by some nodes in
        the path or even none at all.  Allowing nodes to ignore options
        they're not interested in, instead of just discarding the packets,
        preserves the usability of Hop-by-Hop across the whole path.




  Herbert                   Expires 9 April 2024                  [Page 5]


  Internet-Draft                    FAST                      October 2023


     *  [I-D.ietf-6man-hbh-processing] modifies the processing of Hop-by-
        Hop options described in [RFC8200] to make processing of the IPv6
        Hop-by-Hop Options header practical.  In particular, this
        clarifies the expectation that Hop-by-Hop Options should not be
        processed in the slow path and that new Hop-by-Hop options are
        designed to always be processed in the fast path.

     *  [I-D.ietf-6man-eh-limits] specifies that intermediate nodes that
        process Hop-by-Hop Options may set and apply configurable limits
        on Hop-by-Hop Options processing.  For instance, one limit is for
        the number of options that are processed; if the limit is exceeded
        then options processing is terminated and the packet is forwarded
        without any ill-effects.  The use of limits is optional and while
        specific default limits are recommended, there are no specific
        "hard" limits that must be enforced.

     *  [I-D.herbert-eh-inflight-removal] describes a protocol to remove
        Hop-by-Hop Options headers from packets in-flight.  This could be
        applied in FAST by arranging that the last router that processes a
        ticket in a Hop-by-Hop option removes the Hop-by-Hop Options
        header from the packet.  By removing the Hop-by-Hop Options
        header, downstream nodes would allow the packet and no
        functionality is lost since the ticket isn't relevant to the
        downstream routers.

  2.2.2.  Support in IPv4

     A new IPv4 option could be defined to contain tickets.  IPv4 options
     are designed to be inspected by intermediate nodes, however support
     is not widespread to the extent that they may be less deployable than
     even IPv6 Hop-by-Hop Options.  A major reason for this is that the
     IPv4 header, unlike the IPv6 header, is variable length.  Many
     hardware devices have long assumed that the IPv4 header is twenty
     bytes, processing a larger header will likely be problematic causing
     packet discards or packets being relegated to slow path processing.

     An alternative to IPv4 Options is to enable Extension Headers in IPv4
     [I-D.herbert-ipv4-eh] and use Hop-by-Hop Options in IPv4 packets.
     This solution doesn't affect the IP header, but does introduce a new
     IP protocol to IPv4 devices.  Some routers might need to be
     configured to forward IPv4 packets with IP Protocol 0 for Hop-by-Hop
     Options.  This scheme would affect ECMP routing since the transport
     layer headers, continuing the port numbers used in ECMP, would not be
     parsed.  [I-D.herbert-ipv4-eh] describes repurposing the
     Identification field of the IPv4 header to be a flow label to
     compensate for the effects on routers if they can't access transport
     layer headers.




  Herbert                   Expires 9 April 2024                  [Page 6]


  Internet-Draft                    FAST                      October 2023


  3.  Architecture

     The figure below illustrates an example of network paths between
     three communicating hosts.  Each host connects to the Internet via a
     provider network, and provider networks are connected in the Internet
     by transit networks.  In this example, User 1 and User 2 reside in
     Provider A's network and User 2 is in Provider B's network.  With
     respect to FAST, we'll assume User 1 and User 2 are in the same
     limited domain and User 3 is in a different limited domain than User
     1 and User 2.

                                     _____
                     __________     (     )      __________
     +--------+    (          )    (       )    (          )    +--------+
     | User 1 +---( Provider A )--( Transit )--( Provider B )---+ User 3 |
     +--------+    (__________)    (       )    (__________)    +--------+
                         |          (_____)
                     +--------+
                     | User 2 |
                     +--------+
                                     Figure 1

     Within each provider network, services may be provided on behalf of
     the users of the network.  In the figure above, Provider 1 may
     provide services and service agreements for users in its network
     including User 1 and User 2; and likewise Provider B can provide
     services to users in its network including User 3.  We assume transit
     networks don't typically provide user specific services or service
     differentiation.  Services provided by different provider networks
     may be very different and dependent on the implementation of the
     network as well as the policies of the provider.

     Based on this model, services and service differentiation can be
     considered local to each network provider.  FAST is a mechanism
     whereby each user and application can request from its local provider
     the services to be applied to its traffic.  A request for service is
     made to a FAST "ticket agent".  The contents of the request describe
     the services that the application desires.  The ticket agent responds
     with a "ticket" that the application sets in its packets.  The ticket
     has meaning in its "origin network", that is the provider network in
     which the ticket was created.  A ticket provided by a local ticket
     agent is attached to packets as an "origin ticket".

     When a packet is sent by the application with an attached origin
     ticket, the ticket is interpreted by nodes in the local provider
     network as the origin network of the ticket.  The ticket is
     interpreted and processed to allow the packet to traverse the network
     and to map it to the appropriate services.  A ticket is only relevant



  Herbert                   Expires 9 April 2024                  [Page 7]


  Internet-Draft                    FAST                      October 2023


     to the origin network that issued the ticket; to the application
     itself and nodes outside of the provider's network and its limited
     domain, the ticket is an uninterpretable opaque object.

     To facilitate network traversal and service mapping in the reverse
     direction for a flow, that is packets sent from a peer host, peer
     hosts reflect tickets without modification or interpretation.  This
     is done by saving the ticket received in packets of a flow and
     attaching the ticket as a "reflected ticket" to packets being sent on
     the flow.  When a packet with a reflected ticket enters the origin
     network of the ticket, the ticket is processed by a network node to
     allow the packet to traverse the network and to map it to the
     appropriate services.

     The use of tickets may be bilateral for a flow so that each peer
     requests service from its local network.  Therefore packets may
     contain two types of tickets: one that is set by the sending host to
     signal its local provider network, and the other is the reflected
     ticket that is a signal to the provider network of the peer endpoint.

     Tickets are scoped values, they only have meaning in the network in
     which they were issued.  The format, meaning, and interpretation of
     tickets are network specific.  By mutual agreement, two networks may
     share the policy and interpretations of tickets.  For instance, there
     could be an agreement between two provider networks to interpret each
     others tickets or to use a common format.

  3.1.  Example communications flow

     Figure 2 provides an example communications flow using FAST with
     reflected tickets.




















  Herbert                   Expires 9 April 2024                  [Page 8]


  Internet-Draft                    FAST                      October 2023


         1. Ticket                   +--------+
            request  +------------>  | Ticket |
                    /   +----------  | Agent  |
               +---+   /  2. Ticket  +--------+
              / +-----+      reply              ______
             /  v              __________      (      )
         +--------+           (          )    (        )    +--------+
         | Client +----------( Provider A )--( Internet )---+ Server |
         +--------+           (__________)    (        )    +--------+
                                               (______)

       3. App sends,      4,5. Net applies   6. Ignore ticket 7,8. Server
          ticket attached      services         in Internet        reflect
       -------------------> -----------------> --------------------+
                                                                    \
                                   Reverse path                     /
       ------------------ ----------------- --------------------+
        12. Validate           10,11. Network applies  9. Ignore ticket
            reflected ticket          services            in Internet

                                  Figure 2

     Referencing figure 2, consider that the Client is establishing a
     video chat with the Server and wishes to have low latency service for
     video applied by its local network (Provider A).  The flow of events
     may be:

     1.   The Client makes a ticket request to a ticket agent of Provider
          A that describes the video application and may include detailed
          characteristics such as resolution, frame rate, latency, etc.

     2.   The ticket agent issues a ticket to the Client that indicates
          that packets of the flow have a right to traverse the network
          and the services to be applied to the packets of the flow.  A
          ticket reply is sent to the Client.

     3.   The video chat application sends packets for the video chat with
          the ticket attached in Hop-by-Hop Options.

     4.   The first hop node in Provider A's network interprets the ticket
          in packets and applies the appropriate services (e.g.  sets
          diffserv, forwards on a network slice, encapsulates in MPLS,
          encapsulates with segment routing, etc.).

     5.   Packets traverse Provider A's network with the appropriate
          services being applied.





  Herbert                   Expires 9 April 2024                  [Page 9]


  Internet-Draft                    FAST                      October 2023


     6.   Packets traverse transit networks and the Server's provider
          network, the attached tickets are ignored.

     7.   Packets are received at the Server.  Attached tickets are saved
          in the context of the flow for the video chat.

     8.   The Server's video chat application sends packets back to the
          Client.  The last ticket previously received from the Client is
          now reflected in these packets.

     9.   Packets traverse the Server's provider network and transit
          networks, the reflected ticket is ignored.

     10.  An ingress node in Provider A's network interprets the reflected
          ticket and applies appropriate services to the packets for
          traversing the local network.

     11.  Packets are forwarded within Provider's A network with the
          appropriate services applied.

     12.  Packets are received at the host for the Client.  The reflected
          ticket may be validated by comparing the received reflected
          ticket with that being sent for the flow.

  4.  Protocol format

     A ticket is sent in an option in a Hop-by-Hop Options header.

  4.1.  Option format

     The format of a Hop-by-Hop option containing a ticket is:

                            1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Option Type  |  Opt Data Len | Pr|        Ticket Type        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~                         Ticket Data                           ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Fields:

     *  Option Type: Type of Hop-by-Hop option.  This document proposes
        two possible types for FAST ticket options: an unmodifiable and a
        modifiable variant.




  Herbert                   Expires 9 April 2024                 [Page 10]


  Internet-Draft                    FAST                      October 2023


     *  Opt Data Len: Length of the option data field.  The option data is
        comprised the Pr, Ticket Type, and Ticket Data fields.

     *  Pr: Indicates the origin and reflection properties of the ticket.
        Possible values are:

        -  0x0: Origin ticket not reflected.  Don't reflect at receiver

        -  0x1: Origin ticket to be reflected.  Ticket is requested to be
           reflected by the destination host

        -  0x2: Reflected ticket.  The ticket was reflected by a
           destination host and is being returned to the origin source
           host

        -  0x3: Reserved

     *  Ticket Type: The type and format of the ticket.  This value is
        used by nodes in the origin network to interpret the rest of the
        ticket data.  Values for this field are specific to the network
        that issues the ticket.  The type is an IANA managed number space.
        A type of 0 indicates a "null" ticket that isn't to be processed
        by receivers.

     *  Ticket Data: Contains the ticket data that describes the service
        applied.  The format of the data is determined by the Ticket Type.

  4.2.  Option types

     The are two option numbers requested for the ticket option: 0x0F and
     0x2F.  The latter allows modification by network nodes.  Since
     tickets are secured, only the nodes in the network that created a
     ticket will be able to modify it.

  4.3.  Ticket Data format

     The Ticket Data in FAST Ticket option encodes service parameters that
     describe the desired services as well as additional fields that would
     be used to provide privacy and integrity.

     The format of Ticket Data is not fixed and is determined by the
     Ticket Type and the origin network of the ticket.  A ticket should be
     obfuscated or encrypted for privacy so that only the local network
     can interpret it.  It should be uninterpretable to any nodes outside
     the network and to the application or host that is granted a ticket.
     A ticket should be resistant to spoofing so that an attacker cannot
     illegitimately get service by applying a ticket observed on other
     flows.



  Herbert                   Expires 9 April 2024                 [Page 11]


  Internet-Draft                    FAST                      October 2023


     It is RECOMMENDED that tickets are encrypted to prevent unnecessary
     information exposure and abuse of tickets.  It is also RECOMMENDED
     that tickets have an expiration time.  For instance, a ticket may be
     created by encrypting the ticket data with an expiration time and
     using the source address, destination address, and a shared key as
     the key for encryption.

     For example, a ticket with an expiration time may have the format:

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Expiration Time                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        ~                     Service Parameters                        ~
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Where the Expiration Time is in a format understood by the local
     network nodes which maintain synchronized time.  The Service
     Parameters are relevant to local network nodes and describe the
     services to be applied.  The Service Parameters could simply be a set
     of flags for services, an index to a service profile table shared
     amongst the network nodes, or possibly have more elaborate structure
     that could indicate numerical values for characteristics that have a
     range.

     A simple ticket containing a service protocol index might have the
     format:

         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Expiration time                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                  Service Profile Index                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Where the Ticket Type would indicate the Ticket Data contains a
     service profile index.  Service Profile Index could be used as an
     index into a table that describes the services to be applied.

  5.  Operation

  5.1.  Origin and reflection properties

     There are three origin and reflection properties that may be applied
     to a ticket:




  Herbert                   Expires 9 April 2024                 [Page 12]


  Internet-Draft                    FAST                      October 2023


     *  Origin tickets not reflected

     *  Origin tickets to be reflected

     *  Reflected tickets

     Origin tickets are those set by an application that was issued a
     ticket and have an additional property indicating whether they are to
     be reflected by a peer host.  Reflected tickets are those that have
     been received and reflected by a peer host.

     A sender SHOULD set at most one ticket option for each property in a
     packet.  If ticket options with different properties are set within a
     single packet, they SHOULD have the following ordering in the Hop-by-
     Hop Options list:

     *  Origin ticket not reflected

     *  Reflected ticket

     *  Origin ticket to be reflected

     If a packet contains more than one ticket option with the same origin
     and reflection property, only the first ticket option appearing in
     the list for the property is processed.  Additional options for the
     same property MAY be parsed but SHOULD NOT be processed.

  5.2.  Origin application processing

     An origin application requests tickets, sets them in packets, and
     validates reflected tickets.

  5.2.1.  Ticket requests

     An application that wishes to use network services first requests
     tickets from a ticket agent.  The application request could be in the
     form of an XML structure with canonical elements (the definition is
     outside the scope of this document).  The application makes a request
     to a ticket agent in its local network.  This could be done via a web
     service using REST APIs.  Internally in the host, the ticket agent
     might be accessed through a library that interfaces to a ticket
     daemon that in turn arbitrates requests between the applications and
     a ticket agent in the network.

     An issued ticket is opaque to the application and the application
     SHOULD NOT attempt to interpret it or take any other action other
     than to attach the ticket to its packets.




  Herbert                   Expires 9 April 2024                 [Page 13]


  Internet-Draft                    FAST                      October 2023


     A ticket agent MAY provide both an origin ticket not reflected and
     one that is to be reflected.  The intent is that different tickets
     can be used between the forward and return paths for the flow.  In
     the case that two tickets are provided, the origin ticket not
     reflected MUST appear first in the options list and the origin ticket
     to be reflected SHOULD NOT be processed in the forward path.

     The protocols and details for making requests to ticket agents are
     out of scope for this specification.

  5.2.2.  Ticket identification

     Tickets are valid for the specific IP source and destination
     addresses for which they were issued.  Transport layer ports and
     other transport layer information are not included ticket
     identification, however an application can request tickets and
     validate reflected tickets on a per flow basis.  Issued tickets are
     stored in the flow context and the saved information is used to
     validate reflected tickets.

  5.2.3.  Ticket use

     When the ticket agent issues and returns a ticket, the application
     sets the ticket as a Hop-by-Hop option in packets.  This is typically
     done by setting a socket option on a socket (in the case of TCP) or
     by indicating the option in the ancillary data when sending on a
     unconnected socket (in the case of UDP).  The application SHOULD
     continue to use the same ticket for the flow until it is updated with
     a new ticket.

     The ticket agent SHOULD return an expiration time with the ticket.
     An application can use the ticket until the expiration time, at which
     point it can request a new ticket to continue communications.  In
     order to make the ticket transition process seamless, an application
     MAY request a new ticket before the old one expires.

  5.2.4.  Ticket agent delegation

     A network MAY delegate creation of tickets to hosts in a limited
     fashion.  This would entail the network ticket agent issuing a master
     ticket to a host ticket agent which in turn can use the master ticket
     to create a limited number of tickets for its own use.  The details
     of ticket agent delegation are outside the scope of this document.








  Herbert                   Expires 9 April 2024                 [Page 14]


  Internet-Draft                    FAST                      October 2023


  5.3.  Origin network processing

     When a packet with a ticket enters a network, an ingress network node
     can determine if the ticket originated in its network and must be
     processed.  This is done by considering the origin of the ticket and
     the source or destination IP address.  For an origin ticket (i.e. a
     ticket is not reflected), the source address is considered.  If the
     source address is local to the network then the ticket can be
     interpreted.  For a reflected ticket, the destination address is
     considered.  If the destination address is local to the network then
     the ticket can be interpreted.

     If the ticket origin is determined to be the local network then the
     ticket is processed.  The ticket is decrypted if necessary and the
     expiration time is checked.  If the ticket is verified to be
     authentic and valid then the packet is mapped to be processed by the
     requested services.  For instance, in a 5G network the packet may be
     forwarded on a network slice for the characteristics that the
     application has requested (real-time video for instance).

     If an origin ticket cannot be verified, for instance the ticket
     cannot be authenticated, then the ticket SHOULD be ignored and the
     packet processed as though no ticket were present.

     Note that there are logically only two ingress points into the
     network at which a provider needs to process tickets: when a local
     user sends a packet into the provider network with an origin ticket,
     and when a packet from an external network enters the provider's
     network with a reflected ticket.  Typically, a ticket should only
     need to be processed at most once within a network at one of these
     ingress points.  Once a ticket is processed and mapped to the
     network's service mechanisms, it should not normally need further
     processing or examination.

     If there is more than one origin ticket present, then the first one
     encountered is processed and any additional origin tickets SHOULD be
     ignored by a network node.  Note that this will be the case if a
     ticket agent issued both a origin ticket not reflected and one to be
     reflected; the origin ticket not reflected should appear first in the
     packet and thus would be the one processed by nodes in the origin
     network of the ticket.

     If there is more than one reflected ticket present, then the first
     one encountered is processed and any additional reflected tickets
     SHOULD be ignored.






  Herbert                   Expires 9 April 2024                 [Page 15]


  Internet-Draft                    FAST                      October 2023


  5.4.  Destination host processing

     When a host receives a packet with an origin ticket to be reflected,
     it SHOULD save the ticket in its flow context and reflect it on
     subsequent packets.  When the application reflects the option, it
     copies the whole option and only modifies the type to indicate a
     "reflected ticket".  The application SHOULD continue to reflect the
     ticket for packets of the flow until a different one is received from
     the origin or a packet without an origin ticket to be reflected is
     received on the flow.  Note that the latest ticket received is the
     one to be reflected, if packets have been received out of order for a
     flow it is possible that the reflected ticket is from an earlier
     packet in a flow.

     If there is more than one origin ticket to be reflected present, then
     the first one encountered is processed and any additional origin
     tickets to be reflected SHOULD be ignored.

     A destination host MUST ignore received origin tickets not reflected.

  5.5.  Processing reflected tickets

  5.5.1.  Network processing

     When a packet with a reflected ticket enters the origin network of
     the ticket, the ticket SHOULD be processed.  The ticket is validated.
     Validation entails decoding or decrypting the ticket and checking the
     expiration time.  If the ticket is valid and has not expired then the
     ticket is processed.

     A network MAY accept expired reflected tickets for some configurable
     period after the expiration time.  Rate limiting MAY be applied to
     packets with expired reflected tickets.  Accepting expired tickets is
     useful in the case that a connection goes idle and after sometime the
     remote peer starts to send.  The ticket it reflects may be expired
     and presumably the receiving host of the reflected ticket will
     quickly respond with a new origin ticket to be reflected.

  5.5.2.  Host processing

     Upon receiving a packet with a reflected ticket, an end host MAY
     validate the ticket before accepting the packet.  This verification
     is done by comparing the received ticket to that which is set to be
     sent on the corresponding flow.  If the tickets do not match then the
     event SHOULD be logged.

     A host MAY accept expired tickets that are reflected to allow a peer
     time to receive and reflect an updated ticket.



  Herbert                   Expires 9 April 2024                 [Page 16]


  Internet-Draft                    FAST                      October 2023


  5.6.  Removing tickets from packets

     Once the last node in a network path has processed a ticket in a
     packet, any network downstream nodes won't need to access the ticket.
     As stated above, typically only one node in the network needs to
     process a ticket.  Once a ticket has been processed by the last node
     that processes it, it can safely be removed from the packet since
     it's not needed by any downstream nodes.  The motivation for removing
     tickets in-flight is two-fold: 1) It's a security measure to minimize
     visibility of the data, and 2) It simplifies the packet to increase
     chances of successful delivery across a network.

  5.6.1.  Methods to remove tickets

     There are two methods to remove a ticket from a packet:

     *  Create a "null" ticket option by writing zeros in the option data.

     *  Remove the Hop-by-Hop Options header containing the ticket

  5.6.1.1.  Overwriting with a null ticket

     A ticket can be removed from a packet by overwriting the option data
     of the ticket with all zeroes.  The ticket option type MUST be the
     modifiable variant.  Ticket Type 0 is reserved as the "null" type and
     is not processed by any receivers.  Using this method to remove the
     option eliminates visibility of ticket data to downstream network
     nodes.

  5.6.1.2.  Removing Hop-by-Hop Options containing tickets

     Tickets can be removed from packets by removing the Hop-by-Hop Option
     header containing the tickets.  The protocol for removing the Hop-by-
     Hop Options header in-flight is specified in
     [I-D.herbert-eh-inflight-removal].  Note that a Hop-by-Hop Options
     may contain multiple tickets or other unrelated options, if multiple
     options are present then the effects of removing the whole Hop-by-Hop
     Options header should be considered
     ([I-D.herbert-eh-inflight-removal] offers some guidance).

  5.6.2.  Removing tickets without loss of functionality

     A ticket may be removed from a packet without loss of functionality
     under these conditions:







  Herbert                   Expires 9 April 2024                 [Page 17]


  Internet-Draft                    FAST                      October 2023


     *  The last network node that processes a packet containing an origin
        ticket not reflected MAY remove the ticket from a packet.  It may
        be typical that the last network node that processes the ticket is
        the first hop router in the network, so removing the ticket
        minimizes visibility of the ticket data to network nodes.

     *  The last network node that processes a reflected ticket MAY remove
        the ticket from a packet.  It may be typical that the last network
        node to process a reflected ticket will be the ingress network
        node of packets received from an external network.

     An origin ticket to be reflected cannot be removed from a packet
     without affecting functionality.  In order for the ticket to be
     reflected back to the source host, it must be received by the
     destination host.

  5.6.3.  Removing tickets with loss of functionality

     In some cases it may be beneficial to remove tickets from packets at
     the cost of losing some functionality.  For instance, when a packet
     with tickets is exiting a limited domain, it may be better to remove
     the Hop-by-Hop Options header containing the ticket rather than
     forwarding the packet outside of the limited domain and risking that
     the packet will be discarded because it contains a Hop-by-Hop Options
     header.  In the case of FAST, the effects of removing Hop-by-Hop
     Options depends on the properties of tickets in the Hop-by-Hop
     Options that are being removed:

     *  If an origin ticket not reflected is removed then presumably no
        intermediate nodes outside the limited domain would process the
        ticket, so there is no expected loss of functionality.

     *  If an origin ticket to be reflected is removed then the ticket
        will not be seen by the peer host and will thus never be
        reflected.  Ingress routers in the return path from the peer will
        need to employ alternative mechanisms to deduce packet
        characteristics for applying services or may just perform default
        processing of packets.













  Herbert                   Expires 9 April 2024                 [Page 18]


  Internet-Draft                    FAST                      October 2023


     *  If a reflected ticket is removed then the peer network will not
        see the ticket and thus its ingress nodes may need to employ
        alternate mechanisms to deduce packet characteristics for applying
        services or may just perform default processing of packets.  Note
        that when a reflected ticket is sent this indicates that an origin
        ticket to be reflected was received by a destination host.  This
        establishes that Hop-by-Hop Options are viable over the path from
        the original source of the ticket to the reflecting host.  If the
        network path is symmetric in both directions, then this might
        indicate that Hop-by-Hop Options are viable in the return
        direction as well.

     Removing a Hop-by-Hop Options header containing reflected tickets or
     tickets to be reflected when a packet exits a limited domain
     represents a tradeoff.  On one hand, the benefits and functionality
     of ticket reflection are lost, but on the other hand packet discards
     may be avoided so communications are still viable and any origin
     tickets sent can still be applied in the origin network before the
     Hop-by-Hop Options header is removed.  To preserve the benefits as
     much as possible, the limited domain can be extended to be as large
     as possible.  As suggested in Figure 1, if two hosts reside in the
     same limited domain, like User 1 and User 2, then there is no need to
     discard packets with tickets to be reflected or reflected tickets.

     It conceivable that methods like probing could be used to extend the
     limited domain for Hop-by-Hop Options header viability.  For
     instance, a type of Happy Eyeballs probing could be done where hosts
     or network nodes probe the capabilities of a path to a destination by
     sending a number of packets with tickets to be reflected.  The
     sending host can observe whether packets with tickets are being
     properly reflected.  If tickets are successfully being reflected then
     that is evidence that Hop-by-Hop Options are viable the network path
     to and from the destination.  A table of destination networks could
     be distributed to egress routers of the network, and when they
     forward packets with tickets, the routers could consult the table to
     determine if the Hop-by-Hop Options header containing the tickets
     should be removed.

  6.  Implementation considerations

  6.1.  Origin applications

     Existing client applications can be modified to request tickets and
     set them in packets.  The OS networking stack may need some changes
     or configuration to enable an application to specify the Hop-by-Hop
     option in its packets.





  Herbert                   Expires 9 April 2024                 [Page 19]


  Internet-Draft                    FAST                      October 2023


     The interface to the ticket agent would likely be via a library API.


     For a connected socket (TCP, SCTP, or connected UDP socket), a Hop-
     by-Hop option can be set on the socket via the setsockopt system call
     in BSD sockets API.  For an unconnected socket (UDP) the ticket
     option can be set as ancillary data in the sendmsg system call.

  6.2.  Router implementation

     Routers that process tickets will need to process Hob-by-Hop Options
     headers.  As described in [I-D.ietf-6man-hbh-processing], routers
     should process the ticket options in the fast path.  Routers can also
     apply the limits described in [I-D.ietf-6man-eh-limits] to limit
     processing to only FAST options.  For instance, if a Hop-by-Hop
     Options header contains FAST options, the router would need to
     process or parse at most two options (an origin ticket and a
     reflected ticket).  Thus the router could enforce a limit on number
     of Hop-by-Hop options in a packet to be two (presuming there are no
     other Hop-by-Hop Options of interest and that the FAST options always
     precede other Hop-by-Hop options that might not be relevant to the
     router).

     If the tickets defined in a network are all some well known fixed
     length then a router could implement processing of fixed length Hop-
     by-Hop Options headers instead of variable length ones.  Since the
     Hop-by-Hop Options header immediately follows the IPv6 header, the
     combination of the IPv6 header and the Hop-by-Hop Options header
     could be processed as one extended fixed length header.

  6.3.  Ticket reflection

     To perform ticket reflection, servers must be updated.  In the case
     of a connected socket (TCP, SCTP, or a connected UDP socket) this can
     be done as relatively minor change to the kernel networking stack
     which would be transparent to applications.  For unconnected UDP, an
     application could receive the ticket as part of the ancillary data in
     recvmsg system call, and then send the reflected ticket in a reply
     using ancillary data in sendmsg.

  6.4.  Security Considerations

     There are two main security considerations:

     *  Leakage of content specific information to untrusted third parties
        must be avoided.





  Herbert                   Expires 9 April 2024                 [Page 20]


  Internet-Draft                    FAST                      October 2023


     *  Tickets cannot be forged, illegitimately used, or otherwise
        abused.

     Tickets may be visible to the Internet including untrusted and
     unknown networks in the path of sent packets.  Therefore, tickets
     should be encrypted or obfuscated by the origin network.  The details
     of encrypting tickets are outside the scope of this document.

     Tickets need to have an expiration time, must be resistant to
     forgery, and must be non-transferable.  A ticket should be valid for
     the specific source and destination addresses that it was issued for.
     Tickets may be revocable by implemented a black-list contained
     revoked tickets.

  7.  IANA Considerations

     IANA is requested to assigned the following Hop-By-Hop options:

           +-----------+---------------+-------------+---------------+
           | Hex Value | Binary value  | Description | Reference     |
           |           | act chg rest  |             |               |
           +-----------+---------------+-------------+---------------+
           | 0x0F      | 00   0  01111 | Firewall    | This document |
           |           |               | and Service |               |
           |           |               | Ticket      |               |
           +-----------+---------------+-------------+---------------+
           | 0x2F      | 00   1  01111 | Modifiable  | This document |
           |           |               | Firewall    |               |
           |           |               | and Service |               |
           |           |               | Ticket      |               |
           +-----------+---------------+-------------+---------------+

     IANA is requested to set up a registry for the Ticket Property.
     These types are 2 bit values.

           +----------------+--------------------+---------------+
           | Ticket type    | Description        | Reference     |
           +----------------+--------------------+---------------+
           | 0x0            | Ticket from origin | This document |
           |                | and don't reflect  |               |
           +----------------+--------------------+---------------+
           | 0x1            | Ticket from origin | This document |
           |                | and reflect        |               |
           +----------------+--------------------+---------------+
           | 0x2            | Reflected ticket   | This document |
           +----------------+--------------------+---------------+
           | 0x3            | Reserved           | This document |
           +----------------+--------------------+---------------+



  Herbert                   Expires 9 April 2024                 [Page 21]


  Internet-Draft                    FAST                      October 2023


     IANA is requested to create a new sub-registry titled "FAST Ticket
     Types" for ticket types.  The "FAST Ticket Types" registry consists
     of 14-bit hexadecimal values along with descriptive strings,
     assignee/contact information, and references.  The registration rules
     for the new registry are (as defined by [RFC8126]):

           +-------------------+------------------------------------+
           | Range             | Registration Procedures            |
           +-------------------+------------------------------------+
           | 0x0000            | This document ("null" type)        |
           +-------------------+------------------------------------+
           | 0x0001-0x00FF     | IETF Review                        |
           +-------------------+------------------------------------+
           | 0x0100-0x3EFF     | First Come First Served            |
           +-------------------+------------------------------------+
           | 0x3F00-0x3FFF     | Experimental Use                   |
           +-------------------+------------------------------------+

  8.  References

  8.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", STD 86, RFC 8200,
                DOI 10.17487/RFC8200, July 2017,
                <https://www.rfc-editor.org/info/rfc8200>.

  8.2.  Informative References

     [APNIC-EH] Huston, G., "IPv6 extension headers revisited", October
                2022, <https://blog.apnic.net/2022/10/13/ipv6-extension-
                headers-revisited>.

     [I-D.herbert-eh-inflight-removal]
                Herbert, T., "Infight Removal of IPv6 Hop-by-Hop and
                Routing Headers", Work in Progress, Internet-Draft, draft-
                herbert-eh-inflight-removal-01, 2 October 2023,
                <https://datatracker.ietf.org/doc/html/draft-herbert-eh-
                inflight-removal-01>.







  Herbert                   Expires 9 April 2024                 [Page 22]


  Internet-Draft                    FAST                      October 2023


     [I-D.herbert-host2netsig]
                Herbert, T., "Host to Network Signaling", Work in
                Progress, Internet-Draft, draft-herbert-host2netsig-00, 4
                October 2023, <https://datatracker.ietf.org/doc/html/
                draft-herbert-host2netsig-00>.

     [I-D.herbert-ipv4-eh]
                Herbert, T., "IPv4 Extension Headers and Flow Label", Work
                in Progress, Internet-Draft, draft-herbert-ipv4-eh-01, 2
                May 2019, <https://datatracker.ietf.org/doc/html/draft-
                herbert-ipv4-eh-01>.

     [I-D.ietf-6man-eh-limits]
                Herbert, T., "Limits on Sending and Processing IPv6
                Extension Headers", Work in Progress, Internet-Draft,
                draft-ietf-6man-eh-limits-07, 27 September 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
                limits-07>.

     [I-D.ietf-6man-hbh-processing]
                Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
                Processing Procedures", Work in Progress, Internet-Draft,
                draft-ietf-6man-hbh-processing-10, 26 September 2023,
                <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
                hbh-processing-10>.

     [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
                December 1998, <https://www.rfc-editor.org/info/rfc2460>.

     [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
                "Observations on the Dropping of Packets with IPv6
                Extension Headers in the Real World", RFC 7872,
                DOI 10.17487/RFC7872, June 2016,
                <https://www.rfc-editor.org/info/rfc7872>.

     [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
                Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
                <https://www.rfc-editor.org/info/rfc8799>.

     [RFC9098]  Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
                G., and W. Liu, "Operational Implications of IPv6 Packets
                with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
                September 2021, <https://www.rfc-editor.org/info/rfc9098>.

  Author's Address





  Herbert                   Expires 9 April 2024                 [Page 23]


  Internet-Draft                    FAST                      October 2023


     Tom Herbert
     SiPanda
     Santa Clara, CA,
     United States of America
     Email: tom@herbertland.com














































  Herbert                   Expires 9 April 2024                 [Page 24]


name: draft-vattaparambil-positioning-of-poa
rev: 01
title: Positioning of PoA
time: 2024-04-20T07:05:02Z
group_uri: /api/v1/group/group/1027/
expires: 2024-04-20T13:21:38Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:43.021578+00:00
source: ietf
abstract:
  Power of Attorney (PoA) based authorization is a generic and
     decentralized subgranting based authorization technique.  In this, a
     principal can grant limited credibilities for an agent to act on its
     behalf for some limited time and context.  This can be used in both
     constrained and non-constrained environments.  PoA is a self-
     contained document that a principal sign and directs to an agent,
     thereby providing it the power to execute user actions on behalf of
     the principal for a predefined time.  In this document, we compare
     PoA based authorization with different existing internet protocols
     for authorization and the relation with existing identity solutions.

full_text:
  Internet Engineering Task Force                           S. V. Sudarsan
  Internet-Draft                                                O. Schelen
  Intended status: Informational                                  U. Bodin
  Expires: 20 April 2024                    Lulea University of Technology
                                                           18 October 2023


                             Positioning of PoA
                 draft-vattaparambil-positioning-of-poa-01

  Abstract

     Power of Attorney (PoA) based authorization is a generic and
     decentralized subgranting based authorization technique.  In this, a
     principal can grant limited credibilities for an agent to act on its
     behalf for some limited time and context.  This can be used in both
     constrained and non-constrained environments.  PoA is a self-
     contained document that a principal sign and directs to an agent,
     thereby providing it the power to execute user actions on behalf of
     the principal for a predefined time.  In this document, we compare
     PoA based authorization with different existing internet protocols
     for authorization and the relation with existing identity solutions.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 20 April 2024.

  Copyright Notice

     Copyright (c) 2023 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.



  Sudarsan, et al.          Expires 20 April 2024                 [Page 1]


  Internet-Draft              Abbreviated Title               October 2023


     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  Power of Attorney based authorization . . . . . . . . . . . .   3
     3.  Other prominent delegation based authorization standards  . .   4
       3.1.  OAuth . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  GNAP  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.3.  UMA . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.4.  ACE . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.5.  Proxy signature . . . . . . . . . . . . . . . . . . . . .   9
     4.  Existing identity solutions and relation with PoA based
             authorization . . . . . . . . . . . . . . . . . . . . . .   9
     5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     Power of Attorney (PoA) based authorization is a completely generic
     and decentralized delegation or subgranting based authorization
     technique.  It can be used in situations where the user needs to use
     a trusted device to act/work on his/her behalf.  This will enable the
     user to subgrant their power to the trusted device and enable it to
     work on-behalf of the user especially when he/she is not available.
     This authorization technique is based on the traditional legal PoA
     document, which is used by people to transfer control of assets to
     trusted users.  We bring the idea of the legal PoA document into the
     age of Cyber Physical Systems (CPS) and Internet of Things (IoT),
     where humans can instruct their trusted smart devices to act on their
     behalf for a limited time.











  Sudarsan, et al.          Expires 20 April 2024                 [Page 2]


  Internet-Draft              Abbreviated Title               October 2023


     There are existing prominent internet standards for authorization
     especially based on delegation based authorization such as OAuth,
     ACE, GNAP, and UMA.  The objective of this document is to position
     PoA-based authorization by complementing other existing delegation
     based authorization standards and to avoid reinventing existing
     features.  This allows us to understand the key differences between
     them and identify the potential scenarios where PoA-based
     authorization can be used.

  1.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Power of Attorney based authorization

     PoA-based authorization is a generic authorization technique used to
     authorize devices to access protected resources on behalf of the user
     (principal).  Some critical properties of PoA based authorization
     are:

     *  The agent can work on behalf of the principal, even if the user
        (principal) is not online.

     *  The agent can send the PoA to another agent using the multi-level
        authorization feature of PoA based authorization.

     *  The PoA model in its base form is completely decentralized (like
        for example Pretty Good Privacy (PGP)).

     Here the user subgrants their power in the form of a self- contained
     PoA that contains public information such as public keys and a
     specific set of permissions for a predefined time.  Different
     entities involved can access and verify the PoA using a downloadable
     image or library similar to PGP.  Some centralization can be added by
     optional signatory registers and/or traditional Certificate
     Authorities (CA).  The entities (roles) involved in PoA based
     authorization system are:

     *  Principal: The entity that generates, signs, and sends the PoA to
        the agent.

     *  Agent: The device which receives the PoA to act on behalf of the
        principal with limited credentials for a pre-defined time.




  Sudarsan, et al.          Expires 20 April 2024                 [Page 3]


  Internet-Draft              Abbreviated Title               October 2023


     *  Resource server: The third party with a server that stores the
        information and credentials entitled to the principal.  It serves
        agents according to subgrants defined in PoAs.

     *  Signatory registry: A database system where PoAs and system-
        related metadata are stored.  It can serve as a trusted third
        party in certifying and verifying PoA.  This component is
        optional.

     The principal generates the PoA in advance to entitle an agent to
     autonomously execute tasks in the absence of the principal.  The PoA
     is digitally signed by the principal and the agent uses the limited
     features of the principal’s account to execute tasks allowed by the
     PoA.

  3.  Other prominent delegation based authorization standards

     There are different delegation based authorization techniques that
     are important to discuss in relation to PoA based authorization.
     Most of them are centralized methods that rely on a trusted
     authorization server.  Although PoA-based authorization does not rely
     on a centralized server, it also does not use distributed ledger
     technology.  PoA based authorization uses the state of art techniques
     as a foundation and builds an authorization technique that will be
     useful in a subgranting situation in an industrial ecosystem.
     Different prominent delegation-based authorization models are as
     follows:

  3.1.  OAuth

     OAuth is a delegation-based authorization technique, which uses a
     centralized authorization server that issues access tokens to the
     client.  This authorizes the client to access protected resources on
     behalf of the resource owner.  The major tokens used in OAuth are the
     authorization grant token and the access token.  The authorization
     grant represents the resource owner’s authorization, it is generated
     by the resource owner and provided to the client.  The client uses
     the authorization grant to obtain the access token from the
     authorization server.  The access token is used by the client to
     communicate with the resource server to obtain the required
     resources.  There are a few things defined as out of the scope of
     OAuth specification, which are deliberately left for future work to
     make the OAuth protocol more open for future extensions.

     Different grant types in OAuth are authorization code type, where the
     resource owner issues an authorization grant/code for better
     security.  In the implicit type, the access token is directly
     received from the AS without any intermediate tokens.  The resource



  Sudarsan, et al.          Expires 20 April 2024                 [Page 4]


  Internet-Draft              Abbreviated Title               October 2023


     owner password credentials type is used for highly privileged
     clients, where the RO send their username and password to the client.
     The client credentials type is used for the client to access
     resources under its control, where the client uses its credentials as
     an authorization grant to obtain the access token from the AS.  The
     main difference between different OAuth grant types and PoA based
     authorization is that PoA based authorization can be used in a
     scenario where a user (different from RO) has to access the resources
     owned by the RO through the client, even if the user is offline.
     This can be accomplished by transferring the PoA from the user to the
     client, allowing the client to access the resources user's behalf.
     By adding PoA based authorization as a new OAuth grant type, a new
     perspective of delegation can be added to OAuth.

     The main difference between PoA based authorization and OAuth are as
     follows:

     Principal can be offline: In OAuth, there is no entity similar to the
     principal.  The resource owner is the one who delegates the client to
     access resources on behalf of the resource owner.  In PoA based
     authorization, there is another entity called principal, which is
     different from the resource owner and PoA based authorization does
     not require the principal to be online during the process.

     Multi-level authorization: OAuth supports one step of delegation, not
     fully able to separate the resource owner (the main operator) from
     the contractors, and the devices in an arbitrary number of delegation
     levels.  This means OAuth includes only the resource owner entity and
     does not include the principal (contractor) entity.  This means, in
     OAuth the person who provides access privileges is the same as the
     resource owner (person who owns the resources), there is no separate
     entity called the principal (Contractor) who uses the agent/client to
     request the resources owned by the resource owner [OAuth].  In PoA
     based authorization, the PoA received from the principal can be
     transferred by the agent to another trusted number of agents using
     the transfer parameter in PoA.

     Both of these authorization techniques can be used in different
     situations.  The PoA based authorization is used in situations where
     the principal requires the agent to access data from the resource
     server on behalf of the principal.  In PoA based authorization, the
     AS is not defined, because of the self-contained nature of PoAs and
     decentralized operation.  The PoA itself can be used to sign on
     behalf of the principal without any third-party authorization server,
     provided that the resource server and concerned parties are capable
     of processing PoAs.  In contrast, in OAuth, the resources are
     requested by the client for their purpose through a thrid-party
     authorization server that issues access tokens.



  Sudarsan, et al.          Expires 20 April 2024                 [Page 5]


  Internet-Draft              Abbreviated Title               October 2023


     In PoA, a challenge is to enable PoA execution in any system.  This
     could be provided by an open-source lib or a trustworthy downloadable
     image (similar to what is provided for PGP).  Another approach is to
     combine PoA with OAuth [OAuth] that has some level of centralization
     via the authorization server, where some essential parts of PoA
     execution can be handled.

  3.2.  GNAP

     GNAP is an in-progress authorization mechanism that performs
     delegation for a client instance to request delegation or direct
     information from the resource server.  The main roles in GNAP are
     end-user, client instance, authorization server, resource owner, and
     resource server.  The end user operates the client instance
     (software) and interacts with the authorization server to
     authenticate the request.  The client instance requests the
     delegation from the resource server through an authorization server.
     The delegation can be considered as a grant, access token, or other
     information.  GNAP focuses on the delegation process with the client
     instance and provides interoperability between different parties
     involved [GNAP].

     GNAP is designed with a built-in identity, which is usually based on
     cryptographic keys.  This is considered the main difference between
     GNAP and OAuth.  In contrast, PoA based authorization, similar to
     OAuth is not connected with a built-in identity solution.  Physical
     entity identity solutions such as biometric authentication are out of
     the scope of PoA based authorization.

     The PoA-based authorization includes entities that are similar to the
     GNAP, especially the end-user entity.  According to GNAP, the end-
     user is a human entity that operates the client instance, which is
     similar to the principal entity in our proposed model.  However, the
     GNAP specification states that the end user may or may not be the
     same as the resource owner, and in practice, they are usually the
     same.  In addition, there is an information-gathering step in the
     different GNAP authorization modes where they mention the end user
     entity:

     *  basic protocol flow

     *  redirect-based interaction

     *  user code interaction

     *  requesting subject information only





  Sudarsan, et al.          Expires 20 April 2024                 [Page 6]


  Internet-Draft              Abbreviated Title               October 2023


     Here the AS needs to obtain more information from the end user or the
     resource owner (if the end user and the resource owner are the same).
     This indicates that GNAP requires the end user presence even after
     the end user delegation to the client.  To prevent future involvement
     of the end user in the authorization process, GNAP requires a
     stronger delegation or sub-granting process between the end user and
     the client.

     In the Cross User authentication mode, the end user and the RO are
     two different entities.  Here, there is no information-gathering step
     between the AS and the end user because of the first couple of steps
     (steps 1 and 2) in the protocol flow.  However, steps 1 and 2, where
     the end user identifies the RO (which is out of band from the
     protocol; through a phone call) and the end user communicates the
     identifier to the client instance is out of the scope of the
     protocol.  Step 2 is the phase where GNAP and PoA match their
     features.  Step 2, which is out of the scope of GNAP is well-defined
     or is the core part of the PoA-based authorization.

  3.3.  UMA

     UMA [UMA] is an OAuth extension, that adds a requesting party entity
     to OAuth.  In this specification, the client requests the resource
     server on behalf of the requesting party.  The requesting party in
     the UMA specification is similar to the principal in PoA-based OAuth
     extension system.  However, they differ in some aspects.

     In UMA, the client sends a request for resources without any access
     token or permission ticket.  Upon request, the resource server at the
     other end returns a permission ticket that can be used by the client
     in the next step, where the client sends a Request Permission Token
     (RPT) request to the AS.  This includes parameters such as the type
     of grant, ticket (most recent permission ticket received), claim
     token, etc.  Upon receipt of the access token request, with a
     permission ticket, claim token (push claims), the AS sends a 403
     response with a new permission ticket, need info error, and redirect-
     user hint.

     The client redirects the requesting party to AS for interactive
     claims-gathering.  At the endpoint of the authorization server’s
     claims interaction, they request direct interactions with the
     requesting party, such as registration of an account and local
     authentication to the AS as an identity provider, filling out a
     questionnaire, or asking the user to approve the subsequent
     collection of claims through interaction, and continuous storage of
     such claims.





  Sudarsan, et al.          Expires 20 April 2024                 [Page 7]


  Internet-Draft              Abbreviated Title               October 2023


     The UMA specification provides an authorization server redirect of
     requesting party back to the client after an interactive claims-
     gathering.  However, the process of claims- gathering is specified to
     be out of the scope of this specification.

     In PoA-based authorization, the principal (similar to requesting
     party in the UMA) generates and provides his/her PoA to the agent
     (client) which makes the agent work or make requests on behalf of the
     principal.  The information-gathering step, which is not specified in
     the UMA is provided in the form of PoAs in our PoA-based approach,
     where all the required information is included inside the PoA, which
     makes the authorization process more self-contained.

     In UMA, the resource owner/requesting party needs to submit
     credentials by setting policy conditions to the authorization server
     to communicate with the client.  However, in PoA based authorization,
     the principal (similar to the requesting party in the UMA) does not
     necessarily have to communicate with the authorization server to
     interact with the client (agent).

     The UMA protocol flow states that the specification can be used by
     one or two parties.  Here, the requesting party and the resource
     owner could be the same, allowing the specification to be used in two
     different transfer levels.  Similarly, in PoA based system there is a
     PoA parameter named ”transferable” that indicates the number of
     transfers possible with a given PoA, as shown in Fig. 12.  The values
     taken by this parameter are integer values of 0, 1, 2, etc.,
     indicating the number of possible transfers.  This parameter
     increases the transferability scope to a larger scale and, as in UMA,
     is not limited to two parties.  The entire UMA specification requires
     a lot of communication flows between entities, which is eliminated in
     the PoA-based approach that makes it more efficient.

  3.4.  ACE

     ACE is a standard build on top of the OAuth protocol for constrained
     environment.  The use of protocols such as CBOR and CoAP make it
     suitable for constrained environment such as IoT.  The different
     entities in the ACE framework is similar to OAuth standard.  PoA
     based authorization can be used in the ACE framework to add the
     principal entity that provide a notion of delegation in the ACE
     framework.  This may be useful to resolve the client registration and
     AS validation issues in the ACE framework.








  Sudarsan, et al.          Expires 20 April 2024                 [Page 8]


  Internet-Draft              Abbreviated Title               October 2023


  3.5.  Proxy signature

     It is a traditional cryptographic technique that allows a proxy
     signer to sign on behalf of the original signer.  Here, the original
     signer delegates the proxy signer by providing certain credentials,
     using which the proxy signer generates a proxy signature to sign on
     behalf of the original signer.  The original signer can provide the
     delegation in different ways such as full delegation, partial
     delegation, and delegation by warrant [proxy-signature].  The proxy
     signature is a security cryptographic algorithm.  To our
     understanding, the original signer can be offline when the proxy
     signing is executing.  However, proxy signature has not been adapted
     to industry-oriented technique, where the device acts/works on behalf
     of the principal (contractor) for some limited time.

     PoA-based authorization is an industrial authorization technique for
     CPS devices that are designed with different cryptographic
     algorithms, and is similar work as the proxy signature with warrant
     [proxy-signature].  The proxy signature is a significant security
     cryptographic algorithm that strengthens its security by patching
     newer security loopholes.  The main differences are seen in the
     applicability of the technique and the design methodology.  In proxy
     signature, the agent or proxy signer is required to perform several
     cryptographic calculations to sign a message, as described in the
     warrant on behalf of the principal.  PoA can be seen as a more
     industry-oriented technique, where the device acts/works on behalf of
     the principal as described in the PoA.  Here, the agent is only
     required to verify and forward the PoA (received from the principal)
     to the resource owner and provide its strong identity, to obtain the
     resources on behalf of the principal.

  4.  Existing identity solutions and relation with PoA based
      authorization

     PoA based authorization assumes a strong authentication between
     different entities involved using a strong identity solution.  The
     relation of PoA based authorization with the existing identity
     standards and protocols based on Single Sign-On (SSO) are detailed
     below.

     SSO is an authentication mechanism that is built on federated
     identity that allows the principal (user) to use different network
     services without providing the authentication credentials at each
     service.  There are different types of SSO mechanisms such as Secret
     Credential Store, Kerberos, NetWare Authentication, Distributed
     Computing Environment (DCE) Security, X509 Authentication Framework,
     and Pluggable Authentication Module (PAM).  SSO can be implemented
     using SAML and OpenID protocols.  OpenID is a common protocol that is



  Sudarsan, et al.          Expires 20 April 2024                 [Page 9]


  Internet-Draft              Abbreviated Title               October 2023


     used in the SSO authentication process for user identification.
     OpenID Connect provides certified identity to user applications in
     JWT format [SSO].

     SSO can be used along with PoA based authorization to identify the
     principal, agent, and resource owner.  Currently, the authentication
     between different entities in the PoA based authorization is
     implemented using X.509 certificates.

  5.  Summary

     In this draft, we compared the state of the art such as OAuth, GNAP,
     UMA, and proxy signatures that are relevant to discuss with respect
     to PoA based authorization.  The main properties that make the PoA
     different are its offline property, decentralization, and multi-level
     authorization.  Analyzing the existing delegation-based authorization
     standards and protocols, especially the OAuth, PoA based
     authorization can be extended as an additional grant type to OAuth.
     Another approach is a clean state implementation of PoA based
     authorization from the scratch, which provides complete
     decentralization, however, this appears to be a more complex and
     challenging approach.

  6.  References

  6.1.  Normative References

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

  6.2.  Informative References

     [proxy-signature]
                "Proxy signatures: Delegation of the power to sign
                messages,” IEICE transactions on fundamentals of
                electronics, communications and computer sciences, vol.
                79, no. 9, pp.  1338–1354", 1996.

     [OAuth]    Internet Engineering Task Force, "The OAuth 2.0
                authorization framework", 2012.





  Sudarsan, et al.          Expires 20 April 2024                [Page 10]


  Internet-Draft              Abbreviated Title               October 2023


     [GNAP]     Internet Engineering Task Force, "draft-ietf-gnap-core-
                protocol-12", 2022.

     [UMA]      Internet Engineering Task Force, "User-Managed Access
                (UMA) 2.0 Grant for OAuth 2.0 Authorization-12", 2019.

     [SSO]      Internet Engineering Task Force, "Architecture for
                Implementing Network Single Sign-", 2000.

     [Kerberos] Internet Engineering Task Force, "The Kerberos Network
                Authentication Service (V5)", 2005.

  Contributors

     Thanks to all of the contributors.

  Authors' Addresses

     Sreelakshmi Vattaparambil Sudarsan
     Lulea University of Technology
     SE-97187 Lulea
     Sweden
     Email: srevat@ltu.se


     Olov Schelen
     Lulea University of Technology
     SE-97187 Lulea
     Sweden
     Email: olov.schelen@ltu.se


     Ulf Bodin
     Lulea University of Technology
     SE-97187 Lulea
     Sweden
     Email: ulf.bodin@ltu.se














  Sudarsan, et al.          Expires 20 April 2024                [Page 11]


name: draft-ietf-dtn-bpv7-admin-iana
rev: 04
title: Bundle Protocol Version 7 Administrative Record Types Registry
time: 2025-01-17T22:45:19Z
group_uri: /api/v1/group/group/1966/
expires: 2025-04-06T20:30:52Z
ad: /api/v1/person/person/108992/
shepherd: /api/v1/person/email/adam.wiethuechter@axenterprize.com/
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.699345+00:00
source: ietf
source_id: 111982
source_url: https://datatracker.ietf.org/doc/draft-ietf-dtn-bpv7-admin-iana/
doc_status: active
abstract:
  This document updates RFC 9171 to clarify that a Bundle Protocol
     Version 7 agent is intended to use an IANA registry for
     Administrative Record types.  It also makes a code point reservations
     for private and experimental use.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/108/", "/api/v1/doc/state/154/", "/api/v1/doc/state/112/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]

full_text:
  Delay-Tolerant Networking                                       B. Sipos
  Internet-Draft                                                   JHU/APL
  Updates: 9171 (if approved)                               3 October 2024
  Intended status: Standards Track                                        
  Expires: 6 April 2025


       Bundle Protocol Version 7 Administrative Record Types Registry
                     draft-ietf-dtn-bpv7-admin-iana-04

  Abstract

     This document updates RFC 9171 to clarify that a Bundle Protocol
     Version 7 agent is intended to use an IANA registry for
     Administrative Record types.  It also makes a code point reservations
     for private and experimental use.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 6 April 2025.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.




  Sipos                     Expires 6 April 2025                  [Page 1]


  Internet-Draft               BPv7 Admin IANA                October 2024


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Administrative Record Types Registry  . . . . . . . . . . . .   3
     3.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
     4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
       4.1.  Bundle Administrative Record Types  . . . . . . . . . . .   4
     5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
       5.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
       5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   5
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     The earlier Bundle Protocol (BP) Version 6 (BPv6) defined an IANA
     registry for Administrative Record type code points under [IANA-BP].
     When Bundle Protocol Version 7 (BPv7) was published in [RFC9171] it
     identified the IANA registry for Administrative Record types but did
     not update the table to be explicit about which entries applied to
     which Bundle Protocol version(s).  The BPv7 specification also did
     not discriminate between code point reservations and unassigned
     ranges for Administrative Record types.

     This document updates BPv7 to explicitly use the IANA Administrative
     Record type registry in Section 2.  This document makes a reservation
     of the zero value for consistency with BPv6.  This document also
     makes a reservation of high-valued code points for private use and
     experimental use in accordance with [RFC8126] to avoid collisions
     with assigned code points.

  1.1.  Scope

     This document describes updates to the IANA Administrative Record
     type registry and how a BPv7 agent is supposed to use that registry
     for identifying Administrative Record types.

     This document does not specify how BPv6 and BPv7 can interoperate for
     overlapping code points or how a specific code point is to be
     interpreted either similarly or differently between Bundle Protocol
     versions.  It is up to each individual Administrative Record type
     specification to define how it relates to each BP version.







  Sipos                     Expires 6 April 2025                  [Page 2]


  Internet-Draft               BPv7 Admin IANA                October 2024


  1.2.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Administrative Record Types Registry

     This document updates the requirements in Section 6.1 of [RFC9171] to
     use an existing IANA registry and updates that registry in
     Section 4.1.

     The code point allocated in Annex D of [CCSDS-BP] was never added to
     the IANA registry.  To avoid a collision, this document adds that
     allocation to the registry.

     Instead of using the list of types in Section 6.1 of [RFC9171], a
     BPv7 administrative element SHALL interpret administrative record
     type code values in accordance with the IANA "Bundle Administrative
     Record Types" registry under [IANA-BP] for entries having a "Bundle
     Protocol Version" of 7.

     If an administrative element receives a not-well-formed application
     data unit (ADU) or an administrative record type code which is not
     able to be processed by the element, the record SHALL be ignored by
     the element.  The processing of a received administrative record ADU
     does not affect the fact that the bundle itself was delivered to the
     administrative element or any related BPA processing of (e.g. status
     reports on) the enveloping bundle.

  3.  Security Considerations

     This document does not define any requirements or structures which
     introduce new security considerations.

     The existing security considerations of [RFC9171] still apply when
     using the IANA Administrative Record Types registry.

  4.  IANA Considerations

     This specification modifies a BPv6 registry to extend BPv7.








  Sipos                     Expires 6 April 2025                  [Page 3]


  Internet-Draft               BPv7 Admin IANA                October 2024


  4.1.  Bundle Administrative Record Types

     Within the "Bundle Protocol" registry group [IANA-BP], the "Bundle
     Administrative Record Types" registry has been updated to include a
     leftmost "Bundle Protocol Version" column.  New entries have been
     added and existing entries have been updated to have BP versions as
     in the following table.  This document makes no changes to the
     registration procedures for this registry.

      +=================+==========+==================+=================+
      | Bundle Protocol | Value    | Description      | Reference       |
      | Version         |          |                  |                 |
      +=================+==========+==================+=================+
      | 6,7             | 0        | Reserved         | [RFC7116] [This |
      |                 |          |                  | specification]  |
      +-----------------+----------+------------------+-----------------+
      | 6,7             | 1        | Bundle status    | [RFC5050]       |
      |                 |          | report           | [RFC9171]       |
      +-----------------+----------+------------------+-----------------+
      | 6               | 2        | Custody signal   | [RFC5050]       |
      +-----------------+----------+------------------+-----------------+
      | 6,7             | 3        | Unassigned       |                 |
      +-----------------+----------+------------------+-----------------+
      | 6               | 4        | Aggregate        | [CCSDS-BP]      |
      |                 |          | Custody Signal   |                 |
      +-----------------+----------+------------------+-----------------+
      | 6,7             | 5 to 15  | Unassigned       |                 |
      +-----------------+----------+------------------+-----------------+
      | 7               | 16 to    | Unassigned       |                 |
      |                 | 64383    |                  |                 |
      +-----------------+----------+------------------+-----------------+
      | 7               | 64384 to | Reserved for     | [This           |
      |                 | 64511    | experimental use | specification]  |
      +-----------------+----------+------------------+-----------------+
      | 7               | 64512 to | Reserved for     | [This           |
      |                 | 65535    | private use      | specification]  |
      +-----------------+----------+------------------+-----------------+

                  Table 1: Bundle Administrative Record Types

  5.  References

  5.1.  Normative References

     [IANA-BP]  IANA, "Bundle Protocol",
                <https://www.iana.org/assignments/bundle/>.





  Sipos                     Expires 6 April 2025                  [Page 4]


  Internet-Draft               BPv7 Admin IANA                October 2024


     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

     [RFC9171]  Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
                Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
                January 2022, <https://www.rfc-editor.org/info/rfc9171>.

  5.2.  Informative References

     [CCSDS-BP] Consultative Committee for Space Data Systems, "CCSDS
                Bundle Protocol Specification", CCSDS 734.2-B-1, September
                2015, <https://public.ccsds.org/Pubs/734x2b1.pdf>.

     [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
                Specification", RFC 5050, DOI 10.17487/RFC5050, November
                2007, <https://www.rfc-editor.org/info/rfc5050>.

     [RFC7116]  Scott, K. and M. Blanchet, "Licklider Transmission
                Protocol (LTP), Compressed Bundle Header Encoding (CBHE),
                and Bundle Protocol IANA Registries", RFC 7116,
                DOI 10.17487/RFC7116, February 2014,
                <https://www.rfc-editor.org/info/rfc7116>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/info/rfc8126>.

  Acknowledgments


  Author's Address

     Brian Sipos
     The Johns Hopkins University Applied Physics Laboratory
     11100 Johns Hopkins Rd.
     Laurel, MD 20723
     United States of America
     Email: brian.sipos+ietf@gmail.com






  Sipos                     Expires 6 April 2025                  [Page 5]


name: draft-he-yi-srv6ops-ipv6-enhancemnet-in-cloud-uc
rev: 00
title: Use Cases and Requirements for IPv6 enhancement techniques in cloud.
time: 2024-07-05T10:08:58Z
group_uri: /api/v1/group/group/1027/
expires: 2025-01-06T10:08:58Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.703047+00:00
source: ietf
source_id: 136806
source_url: https://datatracker.ietf.org/doc/draft-he-yi-srv6ops-ipv6-enhancemnet-in-cloud-uc/
doc_status: active
abstract:
  This document outlines the use cases for implementing IPv6
     enhancement techniques in cloud, motivated by the increasing demand
     for collabration between cloud and network.  The capabilities of IPv6
     and IPv6 enhancement in most cloud service are not ready, such as
     Service Function Chain based on SRv6, Performance measurement based
     on IPv6.If we want to realize these capabilities of IPv6 enhancement
     end-to-end, we can use a Virtual Incloud Router as anagent which
     support IPv6 and IPv6 enhancement.

full_text:
  Networking                                                    T. He, Ed.
  Internet-Draft                                                X. Yi, Ed.
  Intended status: Informational                              China Unicom
  Expires: 5 January 2025                                      4 July 2024


    Use Cases and Requirements for IPv6 enhancement techniques in cloud.
            draft-he-yi-srv6ops-ipv6-enhancemnet-in-cloud-uc-00

  Abstract

     This document outlines the use cases for implementing IPv6
     enhancement techniques in cloud, motivated by the increasing demand
     for collabration between cloud and network.  The capabilities of IPv6
     and IPv6 enhancement in most cloud service are not ready, such as
     Service Function Chain based on SRv6, Performance measurement based
     on IPv6.If we want to realize these capabilities of IPv6 enhancement
     end-to-end, we can use a Virtual Incloud Router as anagent which
     support IPv6 and IPv6 enhancement.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 5 January 2025.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.










  He & Yi                  Expires 5 January 2025                 [Page 1]


  Internet-Draft    IPv6 enhancement techniques in cloud         July 2024


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   2
       2.1.  SFC based on SRv6 . . . . . . . . . . . . . . . . . . . .   3
       2.2.  Performance measurement based on IPv6 . . . . . . . . . .   3
     3.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   3

  1.  Introduction

     With the rapid development of IPv6 and IPv6 extention protocol, the
     carrier network has basically completed the deployment of them.
     However, in most clouds, IPv4 protocol is still used, and
     IPv6,especially IPv6 extention protocol have not been achieved to
     end-to-end deployment.  In order to promote capabilities of IPv6 and
     IPv6 enhancement into the network end-to-end，such as SFC capability,
     performance measurement based on IPv6/SRv6, etc.，we should upgrade
     the according device and system in the cloud.  But considering the
     upgrading of network hardware devices and business systems in the
     cloud will take a long time and cost a lot, we propose a scheme to
     deploy a Virtual Incloud Router in the cloud to support IPv6 and IPv6
     extention protocol, so that it can realize the end-to-end
     communication and service interaction based on IPv6 and IPv6
     enhancement through the network.

  2.  Use cases











  He & Yi                  Expires 5 January 2025                 [Page 2]


  Internet-Draft    IPv6 enhancement techniques in cloud         July 2024


  2.1.  SFC based on SRv6

     Nowadays, operators are actively evolving from traditional
     communication service providers to integrated information service
     enterprises.  Operators need to organize a large number of value-
     added services in the cloud such as security service product to meet
     the security requirements of enterprises.  At present, SRv6
     technology is the best choice for SFC on the enterprise private line,
     but various security services can not support capability of SRv6 in
     the cloud, so we need to deploy virtual incloud routers in the cloud
     as SRv6 agents of security services, so that the SFC operates well
     end-to-end.

  2.2.  Performance measurement based on IPv6

     iFIT(In-situ Flow Information Telemetry) is a performance measurement
     method based on IPv6, which can monitor network latency and packet
     loss rate.  In the carrier network, some nodes already possessed the
     ability of iFIT, but not yet in the cloud.  End-to-end iFIT
     performance measurement can’t be achieved without the final hop
     measurement from carrier network to the cloud.In order to solve the
     problem, VIR can be deployed in the cloud to support iFIT.

  3.  Conclusion

     Generally, in order to introduce IPv6 capability into the cloud,
     realize the end-to-to IPv6 capabilities , we use VIR to bring quick
     and smart update, which benefits the business with fast evolution.

  4.  Security Considerations

     TBD.

  5.  IANA Considerations

     TBD.

  Acknowledgements

     TBD.

  Contributors

     TBD.

  Authors' Addresses





  He & Yi                  Expires 5 January 2025                 [Page 3]


  Internet-Draft    IPv6 enhancement techniques in cloud         July 2024


     Tao He (editor)
     China Unicom
     Beijing
     China
     Email: het21@chinaunicom.cn


     Xinxin Yi (editor)
     China Unicom
     Beijing
     China
     Email: yixx3@chinaunicom.cn







































  He & Yi                  Expires 5 January 2025                 [Page 4]


name: draft-ietf-sip-location-conveyance
rev: 13
title: Location Conveyance for the Session Initiation Protocol
time: 2024-09-24T23:11:58Z
group_uri: /api/v1/group/group/1462/
expires: 2009-09-10T17:35:34Z
ad: /api/v1/person/person/105791/
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.726340+00:00
source: ietf
source_id: 30924
source_url: https://datatracker.ietf.org/doc/draft-ietf-sip-location-conveyance/
doc_status: active
abstract:
  This document defines an extension to the Session Initiation 
     Protocol (SIP) to convey geographic location information from one 
     SIP entity to another SIP entity.  The extension covers end to end 
     conveyance as well as location-based routing, where SIP servers 
     make routing decisions based on the location of the user agent 
     clients.

full_text:
  SIP Working Group                                            James Polk
  Internet Draft                                            Cisco Systems
  Expires: September 9, 2009                                  Brian Rosen
  Intended Status: Standards Track (PS)                           NeuStar
                                                            March 9, 2009

           Location Conveyance for the Session Initiation Protocol 
                 draft-ietf-sip-location-conveyance-13.txt

  Status of this Memo

     This Internet-Draft is submitted to IETF in full conformance with 
     the provisions of BCP 78 and BCP 79.  This document may contain 
     material from IETF Documents or IETF Contributions published or made
     publicly available before November 10, 2008.  The person(s) 
     controlling the copyright in some of this material may not have 
     granted the IETF Trust the right to allow modifications of such 
     material outside the IETF Standards Process.  Without obtaining an 
     adequate license from the person(s) controlling the copyright in 
     such materials, this document may not be modified outside the IETF 
     Standards Process, and derivative works of it may not be created 
     outside the IETF Standards Process, except to format it for 
     publication as an RFC or to translate it into languages other than 
     English.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six 
     months and may be updated, replaced, or obsoleted by other documents
     at any time.  It is inappropriate to use Internet-Drafts as 
     reference material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt.

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     This Internet-Draft will expire on September 9, 2009.

  Copyright Notice

     Copyright (c) 2009 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents in effect on the date of
     publication of this document (http://trustee.ietf.org/license-info).
     Please review these documents carefully, as they describe your 


  Polk & Rosen              Expires Sept 9, 2009                 [Page 1]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     rights and restrictions with respect to this document.

  Legal

     This documents and the information contained therein are provided on
     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
     IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
     WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
     WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
     ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
     FOR A PARTICULAR PURPOSE.

  Abstract

     This document defines an extension to the Session Initiation 
     Protocol (SIP) to convey geographic location information from one 
     SIP entity to another SIP entity.  The extension covers end to end 
     conveyance as well as location-based routing, where SIP servers 
     make routing decisions based on the location of the user agent 
     clients.


  Table of Contents 
       
     1.  Conventions and Terminology used in this document . . . . . .  3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.  Overview of SIP Location Conveyance . . . . . . . . . . . . .  6
     4.  SIP Modifications for Geolocation Conveyance  . . . . . . . .  7
         4.1 The Geolocation Header  . . . . . . . . . . . . . . . . .  7
         4.2 424 (Bad Location Information) Response Code  . . . . . . 11
         4.3 The Geolocation-Error Header  . . . . . . . . . . . . . . 11
         4.4 The 'geolocation' Option Tag  . . . . . . . . . . . . . . 20
         4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 20
     5.  Geolocation Examples  . . . . . . . . . . . . . . . . . . . . 21
         5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 22
         5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 23
     6.  SIP Element Behavior  . . . . . . . . . . . . . . . . . . . . 24
         6.1 UAC Behavior  . . . . . . . . . . . . . . . . . . . . . . 25
         6.2 UAS Behavior  . . . . . . . . . . . . . . . . . . . . . . 28
         6.3 Proxy Behavior  . . . . . . . . . . . . . . . . . . . . . 33
     7.  Geopriv Privacy Considerations  . . . . . . . . . . . . . . . 36
     8.  Security Considerations . . . . . . . . . . . . . . . . . . . 37
     9.  IANA Considerations   . . . . . . . . . . . . . . . . . . . . 38
         9.1 IANA Registration for New SIP Geolocation Header  . . . . 38
         9.2 IANA Registration for New SIP 'geolocation' Option Tag  . 39
         9.3 IANA Registration for New 424 Response Code . . . . . . . 39
         9.4 IANA Registration for New SIP Geolocation-Error Header  . 39
         9.5 IANA Registration for New SIP Geolocation-Error Codes . . 39
         9.6 IANA Registration of LbyR Schemes   . . . . . . . . . . . 40
     10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 40
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . . 41


  Polk & Rosen              Expires Sept 9, 2009                 [Page 2]
  Internet Draft         Location Conveyance in SIP              Mar 2009

         11.1 Normative References   . . . . . . . . . . . . . . . . . 41
         11.2 Informative References . . . . . . . . . . . . . . . . . 42
         Author Information  . . . . . . . . . . . . . . . . . . . . . 42
         Appendix A. Requirements for SIP Location Conveyance  . . . . 43
         Appendix B. Example of Civic-based PIDF-LO w/ S/MIME  . . . . 45


  1.  Conventions and Terminology used in this document

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
     "OPTIONAL" in this document are to be interpreted as described 
     in [RFC2119].

     The following terms and acronyms used throughout this document are 
     defined here:

     "cid=" = content-ID URI. See Section 4.1 for more details.

     Content-ID - Defined in RFC 2392 as a URL reference to find message 
         body parts within the same message, to ease parsing.  

     LbyR = Location-by-Reference

     LbyV = Location-by-Value 

     locationErrorValue - contains an actionable error code from a 
        Location Recipient, identifying the location "inserter=", and 
        optionally a test string describing the type of error.  There can
        be one or more locationErrorValues within a Geolocation-Error 
        header in a SIP response. See Section 4.3 for more details.

     locationValue - contains a URI pointing to a Location Target's 
        location (as a PIDF-LO), and one or more header parameters about 
        that URI. There can be one or more locationValues within a 
        Geolocation header in a SIP request. See Section 4.1 for more 
        details.

     Location Generator - the first IP enabled device that builds the IP 
        packet that transmits the PIDF-LO containing the Target's 
        location

     Location Information Server (LIS) - a logical server that stores 
        geolocation records, which correspond to LbyR URIs, which point 
        to those records.

     Location Object - Defined in RFC 4119 as the PIDF-LO (XML scheme) 
        format which includes the geolocation of Location Target in 
        either civic address or coordinate form.

     Location Recipient - Defined in RFC3693 as any entity that 
        understands geolocation (LbyR or LbyV) along a message path.  


  Polk & Rosen              Expires Sept 9, 2009                 [Page 3]
  Internet Draft         Location Conveyance in SIP              Mar 2009

        Does not include entities that process a message containing 
        geolocation that do not understand geolocation (i.e., layer 3 
        routers).

     Location Server - a logical IP server that transmits a PIDF-LO. This 
        can be logically combined with the Location Generator, or could 
        be an intermediary element - such as a LIS.

     Location Target - The entity whose location is being sought, whether
        or not this entity is aware of this inquiry or is even an IP 
        device.

     Location-by-Reference (more than one meaning)

      - a general purpose term meaning a message containing a URI that 
        points to a PIDF-LO (geolocation of a Location Target) not within
        this same message

      - a URI that logically locates a geolocation record of a Location 
        Target.  The URI does not point to location within the same 
        message as the URI.

     Location-by-Value - when a message contains the actual location of a
        Location Target, in the form of a PIDF-LO, within a part of the 
        same message, usually pointed to by a "cid=" URI in a Geolocation
        header.

     Using Protocol - as defined in [RFC3693], a protocol that is deemed 
        to be in compliance with the security and privacy aspects of the 
        Geopriv Requirements RFC [RFC3693], with good community 
        verification.

     Instead of using the terms Location-by-Reference (or just 
     by-reference) and Location-by-Value (or just by-value), this 
     document will herein use the acronyms LbyR and LbyV, respectively. 
     The use of "cid=" implies LbyV, therefore, the use of a "cid=" 
     Reference URL, which is *not* a Location-by-Reference (LbyR).


  2.  Introduction

     This document describes how Location can be "conveyed" (that is, 
     transmitted over the Internet) from one SIP user agent (UA), or in 
     some circumstances, a proxy server acting in support of a UA, to 
     another entity using SIP [RFC3261].  Here "Location" is a 
     description of the physical geographical area where something 
     currently exists.  The phrase "location conveyance" describes 
     scenarios in which a SIP user agent client (UAC) is informing a user
     agent server (UAS) or intermediate SIP server where the UAC is.  A
     superset of this can also be true as well, in which one UA (UA-1) is 
     telling another UA-2 where another Target is, meaning not 
     necessarily where UA-1 is.  The key to this is whether UA-1 has 


  Polk & Rosen              Expires Sept 9, 2009                 [Page 4]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     permission to retransmit that other Target's location.  If yes, then
     this is valid.  If no, then this is breaking a fundamental rule 
     within this extension.

     Location Conveyance is different from a UAC seeking the location the
     UAS.  Location conveyance is a 'sending location out in the request'
     model, where 'asking that someone else's location be in a response' 
     is not discussed here. 

     Geographic location in the IETF is discussed in RFC 3693 (Geopriv 
     Requirements) [RFC3693].  It defines a "Target" as the entity whose 
     location is being sought.  In this case, this is the UA's 
     (UA) location.  A [RFC3693] "Using Protocol" defines how a "Location
     Server" transmits a "Location Object" to a "Location Recipient" 
     while maintaining the contained privacy intentions of the Target 
     intact. This document describes the extension to SIP for how it 
     complies with the Using Protocol requirements, where the location 
     server is a UA or Proxy Server and the Location Recipient is
     another UA or Proxy Server.

     Location can be transmitted by-value or by-reference.  The location 
     "value" in this SIP extension is in the form of a Presence 
     Information Data Format - Location Object, or PIDF-LO, as described 
     in [RFC4119].  A PIDF-LO is an XML Scheme specifically for carrying 
     geographic location of a Target.  LbyV refers to a UA including a 
     PIDF-LO as a body part of a SIP request, sending that Location 
     Object to another SIP element.  LbyR refers to a UA or proxy server 
     including a URI in a SIP request header field which can be 
     dereferenced by a Location Recipient for a Location Object, in the 
     form of a PIDF-LO.  Dereferencing can be by a SIP UA or a SIP 
     server.

     As recited in RFC 3693, location often must be kept private.  The 
     Location Object (PIDF-LO) contains rules which provides guidance to 
     the Location Recipient and controls onward distribution and 
     retention of the location.  This document describes the security and
     privacy considerations that must be applied to location conveyed 
     with SIP.

     Another use for location is location-based routing of a 
     SIP request, where the choice of the next hop (and usually, the 
     outgoing Request-URI) is determined by the location of the UAC which
     is in the message by-value or by-reference.  This document describes
     how location can be conveyed from the UAC, or a proxy acting on its 
     behalf, to a routing proxy.  How the location is actually used to 
     determine the next hop or Request-URI is beyond the scope of this 
     document.

     We refer to the "emergency case".  This refers to a specific, 
     important use of SIP location conveyance where the location of the 
     caller is used to determine which Public Safety Answering Point 
     (PSAP) is expected to receive an emergency call request for help 


  Polk & Rosen              Expires Sept 9, 2009                 [Page 5]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     (e.g., a call to 1-1-2 or 9-1-1).  This is an example of
     location-based routing.  The location conveyed is also used by the 
     PSAP to dispatch first responders to the caller's location.  There 
     are special security considerations, which make the emergency case 
     unique, compared to a normal location conveyance within SIP.

     Common terms are in Section 1. Section 3 provides an overview of SIP
     location conveyance.  Section 4 details the modifications necessary 
     to accomplish location conveyance.  Section 5 gives decode examples 
     of geolocation within SIP requests, both LbyV and LbyR.  Section 6 
     articulates the SIP element type behaviors for location conveyance. 
     Section 7 discusses Geopriv privacy considerations.  Section 8 
     discusses security considerations.  Section 9 IANA registers the 
     modifications made to SIP by this document from section 4.


  3.  Overview of SIP Location Conveyance

     This document defines a new SIP header: Geolocation.  The 
     Geolocation header field contains a URI which can either be a "cid:"
     URI (Content Identification), as defined in [RFC2392], or an LbyR 
     -- to be dereferenced by a Location Recipient to retrieve the 
     location of the Target UA.  

     Where the Geolocation header contains a "cid:", the URI points to a 
     message body that is in the form of a PIDF [RFC3863], which was 
     extended in [RFC4119] to include location, as a PIDF-LO. This is 
     LbyV, the actual location information in the PIDF-LO is included in 
     the body of the message.  

     If the URI in the Geolocation header field is a scheme other than 
     "cid:", another protocol operation is needed by the SIP message 
     recipient to obtain the location of the Target (UA).  This is 
     LbyR. This document describes how a SIP presence subscription 
     [RFC3856] can be used as a dereference protocol.

     The Geolocation header, either with the PIDF-LO in a body or as a 
     LbyR URI, can be included by a UA in a SIP request.  A SIP proxy 
     server can assert location of the UA by inserting the header field, 
     by adding an LbyR URI into the Geolocation header value, even if 
     there is a locationValue already there.  Since body parts cannot be 
     inserted by a SIP proxy server, LbyV message body cannot be inserted
     by a proxy.

     The Geolocation header can have parameters that are associated 
     with a URI in the header field.  The "inserted-by" parameter 
     indicates the host-id of which specific element added this 
     particular location to the request. This header parameter is 
     included in every locationValue, and does not appear more than once 
     per locationValue.  The "inserted-by" parameter is especially useful
     for Location Recipients that receive more than one locationValue 
     within a SIP request.  Since implementations of a UA or SIP Server 


  Polk & Rosen              Expires Sept 9, 2009                 [Page 6]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     do not know they will be the last entity before a Location 
     Recipient, this optional parameter is necessary within each 
     locationValue.

     Retargeting means the Request-URI of the request has changed to 
     point at a new destination UAS.  This is different than message 
     routing, that all SIP proxies do.  If a SIP request is retargeted 
     based on the location contained or referenced within that message, 
     the "used-for-routing" parameter is added as a header parameter
     within the appropriate locationValue.  
     
     There is no mechanism by which the veracity of these parameters can 
     be verified.  They are hints to downstream entities on how the 
     location information in the message was originated and used.  
     Transport Layer Security is expected when a request contains a 
     user's location.  Some implementations will choose to have S/MIME to 
     encrypt message bodies from source to destination.

     This document creates a new option tag: geolocation, to indicate 
     support for this extension by UAs.  

     A new error response (424 Bad Location Information) is also defined 
     in this document. Within this response is a new header indicating 
     location-based errors, call the Geolocation-Error header.  This 
     header has various codes that provide additional information about 
     the type of location error experienced by a Location Recipient.

     The new headers, the header parameters, the new option tag, the new
     error response, and Geolocation-Error codes, which are defined in 
     Section 4., are IANA registered by this document.


  4.  SIP Modifications for Geolocation Conveyance

     The following are sections detail the standards track modifications 
     to SIP for Location Conveyance.  

  4.1 The Geolocation Header

     This document defines and IANA registers a new SIP header: 
     Geolocation, with the following ABNF [RFC5234]:

     Geolocation        =  "Geolocation" HCOLON (locationValue *(COMMA
                            locationValue)) (COMMA retrans-param)
     locationValue      =  LAQUOT locationURI RAQUOT *(SEMI geoloc-param)
     locationURI        =  sip-URI / sips-URI / pres-URI 
                            / cid-url ; (from RFC 2392)
                            / absoluteURI ; (from RFC 3261)
     geoloc-param       =  "inserted-by" EQUAL geoloc-inserter
                            / "used-for-routing"
                            / generic-param ; (from RFC 3261)
     geoloc-inserter    =  DQUOTE hostport DQUOTE


  Polk & Rosen              Expires Sept 9, 2009                 [Page 7]
  Internet Draft         Location Conveyance in SIP              Mar 2009

                            / gen-value ; (from RFC 3261)
     retrans-param      =  "routing-allowed" EQUAL "yes" / "no"

     sip-URI, sips-URI and absoluteURI are defined according to RFC 3261.
     The pres-URI is defined in RFC 3859 [RFC3859].

     The cid-url is defined in [RFC2392] to locate message body 
     parts.  This URI type MUST be present in a SIP request if location 
     is transmitted LbyV only.

     Other protocols used in the Location URI MUST be reviewed against 
     the RFC 3693 criteria for a Using Protocol.

     The Geolocation header MAY have one or more locationValues. SIP 
     servers inserting a locationValue MUST add the new value as the last
     locationValue in the Geolocation header (i.e., the last 
     locationValue in the header is the most recent one added to the 
     message).  Placement of the "routing-allowed" parameter, when 
     present, MUST be the last header value in the Geolocation header.

     A locationValue has the following independent header parameters,

     o  the "inserted-by=" parameter provides the hostport 
        (alice.example.com -- which is the same as the "sent-by" 
        parameter in a Via header, with or without a port number) of the 
        SIP entity that inserted this locationValue into the request. If 
        a Location Recipient has determined a supplied location is in 
        error, as there can be more than one in any request, the 
        "inserted-by=" parameter is copied into the locationErrorValue in
        the response indicating the location error, and to whom the error
        is for.  Hence, this "inserted-by=" parameter MUST be present in 
        each locationValue. If an entity receives an Geolocation-Error 
        with a hostport not identifying this entity, the 
        Geolocation-Error MUST be ignored.

     o  the "used-for-routing" parameter to inform recipients that the 
        location in this locationValue was used to route the message 
        towards the ultimate destination UAS.  "used-for-routing" can 
        occur more than once along the request's path.  Because 
        locationValues are inserted as last inserted is last in the 
        header, the last locationValue is the most recent one added to 
        the message.  This also gives the "used-for-routing" header 
        parameter added meaning - as the receiving SIP entity knows which
        locationURI the message was routed upon.

     Each locationValue MUST contain exactly one "inserted-by" parameter,
     indicating which SIP entity added the locationValue to the SIP 
     request.  

     There MUST NOT be more than one "inserted-by=" parameter or one 
     "used-for-routing" parameter in the same locationValue.  However, 
     there can be more than one locationValue in the same Geolocation 


  Polk & Rosen              Expires Sept 9, 2009                 [Page 8]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     header.

     The "routing-allowed" header parameter is a global parameter over 
     any (and all/each) locationValues in the Geolocation header.  This 
     is the reason why the placement of the header parameter is outside 
     any locationValue, and appears only once, and is always last in the 
     header value.

     This header parameter has values "=yes" or "=no" only.  When this 
     parameter "=yes", any locationValue can be used for routing 
     decisions along the downstream signaling path by intermediaries.  
     When this parameter "=no", this means no locationValue (inserted by 
     the originating UAC or any (or subsequent) intermediary(ies) along 
     the signaling path) can be used by any SIP intermediary to make 
     routing decisions.  This behavior MUST be adhered to.

     The practical implication is that when the "routing-allowed" 
     parameter is set to "no", if an LbyV is present in the SIP request, 
     intermediaries SHOULD NOT view the location (because it is not
     for intermediaries to view), and if an LbyR is present, SHOULD NOT 
     dereference it.  UASs are allowed to view location in the SIP 
     request even when the "routing-allowed" header parameter is set to 
     "no".

     The default behavior when this header parameter is not present in a 
     message is to treat the SIP request as if the parameter were present
     and its value is set to "no".

     This document defines the Geolocation header as valid in the 
     following SIP requests:

        INVITE [RFC3261],             REGISTER [RFC3261],
        OPTIONS [RFC3261],            BYE [RFC3261],
        UPDATE [RFC3311],             INFO [RFC2976],
        MESSAGE [RFC3428],            REFER [RFC3515],
        SUBSCRIBE [RFC3265],          NOTIFY [RFC3265],
        PUBLISH [RFC3903] and         PRACK [RFC3262]


     Discussing location using the PUBLISH request is out of scope 
     for this document since it is part of Presence, therefore, for 
     completeness, Table 1 shows PUBLISH is to support Location 
     Conveyance via this extension, but is not discussed further.  











  Polk & Rosen              Expires Sept 9, 2009                 [Page 9]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     The following table extends the values in Table 2&3 of RFC 3261
     [RFC3261].  

        Header field             where proxy INV ACK CAN BYE REG OPT PRA
        ----------------------------------------------------------------
        Geolocation              R     ar     o   -   -   o   o   o   o

        Header field             where proxy SUB NOT UPD MSG REF INF PUB
        ----------------------------------------------------------------
        Geolocation              R     ar     o   o   o   o   o   o   o

                 Table 1: Summary of the Geolocation Header 

     The Geolocation header field MAY be included in any one of the above
     requests by a UAC.  A proxy MAY add the Geolocation header, but MUST
     NOT modify any pre-existing locationValue, including any associated 
     header parameters within an existing Geolocation header value, 
     unless one of the existing locationValues is used to retarget the 
     request towards a new destination UAS.  This is discussed in section
     6.3.   

     [RFC3261] states message bodies cannot be added by proxies.  
     Therefore, any Geolocation header field added by a proxy MUST be in 
     the form of an LbyR URI, in its own locationValue header value.  

     A SIP proxy MAY add a Geolocation header if one is not present, and 
     MAY add the "routing-allowed" parameter if not yet present in the 
     SIP request.  When a "routing-allowed" parameter is already present 
     in the SIP request, a SIP server MUST NOT change the value of the 
     parameter (i.e., from 'yes' to 'no', or from 'no' to 'yes').  This 
     would override the policy set by an upstream SIP entity (i.e., 
     likely the UAC).

     Adding a new locationValue to an in-transit request SHOULD NOT
     occur for at least two reasons,

     #1 - SIP Servers are not the best Sighters, as defined by [RFC3693],
          of geographically where a UAC can be; meaning the location 
          information is not necessarily the greatest.  There MAY be 
          exceptions, but this SHOULD be the rule of thumb. 

     #2 - without appropriate caution to the fact that Location 
          Recipients might not understand how to process more than one 
          location, given this document's limited guidance as to what a 
          Location Recipient should do when receiving more than one 
          location  (i.e., currently no priority instructions are given 
          for which locationValue to use if there are more than one).  A 
          Location Recipient can easily be confused by too much location 
          information, producing undesirable results.  The <tuple id> 
          element in the PIDF-LO XML indicates whose location is 
          contained in the PIDF-LO. 



  Polk & Rosen              Expires Sept 9, 2009                [Page 10]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     Location Recipients receiving a location object, received directly 
     or as the result of a dereference, MUST honor the usage element 
     rules within that XML document, as defined in [RFC4119].  Such 
     entities MUST NOT alter the rule set.


  4.2 424 (Bad Location Information) Response Code

     This SIP extension creates a new Location specific response code, 
     defined as follows.

        424 (Bad Location Information)

     The 424 (Bad Location Information) response code is a rejection of 
     the request, due to its location contents, indicating the location 
     information was malformed or not satisfactory for the recipient's 
     purpose, or could not be dereferenced.  

     Section 4.3 creates the Geolocation-Error header to provide more 
     detail about what was wrong with the location information in the 
     request.  This header MUST be in the 424 response, containing a 
     locationErrorValue for each invalid locationValue in the request 
     (i.e., and one-for-one matching if all locationValues in the request
     were bad).

     If more than one location is present in a request (LbyV or LbyR), 
     and any of the locationValues is good for the Location Recipient to 
     process, a 424 MUST NOT be sent.  The 424 is only appropriate when 
     the Location Recipient needs a locationValue and there are no 
     locationValues included in a SIP request that are usable by a 
     recipient.

     A 424 (Bad Location Information) response is a final response within
     a transaction, and does not terminate a usage or a dialog.

     The UAC can use whatever means it knows of to verify/refresh its 
     location information before attempting a new request that includes 
     location. There is no cross-transaction awareness expected by either
     the UAS or any SIP intermediary as a result of this error message.

     The new 424 (Bad Location Information) error code is IANA registered
     in Section 8 of this document.  An initial set of location error of 
     IANA registered Geolocation-Error codes are in Section 4.3 of this 
     document.


  4.3 The Geolocation-Error Header 

     As discussed in Section 4.2, more granular error notifications, 
     specific to location errors within a received request, are required 
     if the UAC is to know what was wrong within the original request.  
     The Geolocation-Error header is created here for this purpose.  


  Polk & Rosen              Expires Sept 9, 2009                [Page 11]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     Geolocation-Error header is used to convey location specific errors 
     within a response.  Additions to this IANA registered header require
     an RFC be published. The Geolocation-Error header has the following 
     ABNF [RFC5234]:

     Geolocation-Error        = "Geolocation-Error" HCOLON 
                                  locationErrorValue
                                 *(COMMA locationErrorValue)
     locationErrorValue       = location-error-code *(SEMI 
                                 location-error-params)
     location-error-code      = 1*3DIGIT
     location-error-params    = location-error-node-id
                                / location-error-host-id 
                                / location-error-code-text 
                                / generic-param ; from RFC3261
     location-error-node-id   = "node" EQUAL 
                                   DQOUTE hostport DQOUTE ; from RFC3261
     location-error-host-id   = "inserter" EQUAL 
                                   DQOUTE hostport DQOUTE ; from RFC3261
     location-error-code-text = "code" EQUAL quoted-string ; from RFC3261


     The Geolocation-Error header MUST contain at least one 
     locationErrorValue to indicate what was wrong with the original 
     locationValue in the corresponding request. If a Location Recipient 
     experienced more than one error a particular locationValue of the 
     corresponding SIP request, there can be one locationErrorValue per 
     problem with the locationValue in the request.  Each 
     locationErrorValue contains one 3-digit error code indicating what 
     was wrong with the location in the request.  Each error type has a 
     corresponding quoted error text string that is human 
     understandable.  If there was something wrong with more than one 
     locationValue in a request, a corresponding locationErrorValue would
     be sent, one per error, in the response.  

     Each locationErrorValue contains the Location Recipient identifier 
     (the "node=" parameter) which experienced the location error, as 
     well as an identifier of which SIP entity (the "inserter=" 
     parameter) the Location Recipient is told (in the locationValue) 
     added this problematic locationValue to the request.  The "node=" 
     and "inserter=" are the domain identifier of a SIP entity, with the 
     ability to have the same host communicate on different ports - and 
     have port specific identification. This is the same as is entered in
     the "sent-by" parameter of the Via header for that entity 
     [RFC3261].  As stated in section 18 of RFC 3261, the usage of FQDN 
     is RECOMMENDED.  Here are examples of both locationErrorValue 
     parameters

        node="bob.example.com"

        inserter="alice.example.com"



  Polk & Rosen              Expires Sept 9, 2009                [Page 12]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     Both the "node=" and "inserter=" parameters MUST be present in all 
     locationErrorValues in a response, unless the "inserted-by=" 
     parameter was not in the locationValue of a request (which is a 
     violation of this document).  The "inserter=" parameter value is 
     copied from the "inserted-by=" parameter within the locationValue of
     the request.  No manipulation or calculation is necessary to 
     accomplish this.

     Here's why this is necessary, a Location Recipient that experienced 
     the location problem with the request needs to tell the specific SIP
     entity which added the locationValue in error into the original 
     request.  Since more than one SIP entity can insert location into a 
     request in transit, all other SIP elements may be confused by 
     receiving this error header, were it to remain generic to all 
     entities in the response path.  So, the header has to identify who 
     it is for, so that all other SIP entities that read the header know 
     to ignore it, since it is not for them.  This is of particular use 
     if the original UAC did not include a locationValue in the original 
     SIP request, but a SIP server along the path did insert a 
     locationValue.  The locationErrorValue would travel to each SIP 
     entity along the original path and tell both the server that 
     included the locationValue what was wrong with the location and the 
     UAC who did not know what the error meant.  This will cause 
     confusion if left without this indication.

     A worse case is when both the original UAC and a SIP server along 
     the path included a locationValue, but there was only something 
     wrong with one of the locationValues.  Without this identification 
     of which locationValue was in error, both entities would react and 
     one would do so incorrectly.

     More than one locationErrorValue in a Geolocation-Error header is 
     separated by a comma.  

     If more than one locationErrorValue is in a response, and intended 
     for the same "inserter=", each error code MUST be unique to this 
     "inserter=" entity, and the error codes SHOULD NOT conflict in 
     meaning.  In other words, two error codes (within separate 
     locationErrorValues of the same response) SHOULD NOT give misleading
     or inconsistent indications to the location "inserter=".  

     Here is an example of a Geolocation-Error header

     Geolocation-Error: 200; code="Retry Location Later"; 
                              node="bob.example.com"; 
                              inserter="alice.example.com"; 

     The following table extends the values in Table 2&3 of RFC 3261
     [RFC3261].  





  Polk & Rosen              Expires Sept 9, 2009                [Page 13]
  Internet Draft         Location Conveyance in SIP              Mar 2009

        Header field             where proxy INV ACK CAN BYE REG OPT PRA
        ----------------------------------------------------------------
        Geolocation-Error         r     ar    o   -   -   o   o   o   o

        Header field             where proxy SUB NOT UPD MSG REF INF PUB
        ----------------------------------------------------------------
        Geolocation-Error         r     ar    o   o   o   o   o   o   o

              Table 2: Summary of the Geolocation-Error Header 

     The Geolocation-Error header field MAY be included in any response 
     to one of the above SIP requests, so long as Geolocation was in the 
     request part of the transaction.  The choice of which SIP requests 
     are in table 2 above come from which Methods can optionally have the
     Geolocation header (see section 4.1).  That said, a UAC MUST ignore 
     a Geolocation-Error header value if it did not include a Geolocation
     header value in the request part of the transaction.

     Here is an example of a transaction that has a location error.  In 
     this case, Bob responds with a 424 (Bad Location Information) 
     response, including a Geolocation-Error header, is in Figure 1.

        Alice                                              Bob       
          |                                                 |        
          |       Request w/ Location                       |        
          |------------------------------------------------>|        
          |                                                 |        
          |                                                 |        
          |  424 (Bad Location Information)                 |        
          |  with Geolocation-Error containing              |        
          |  200 ("Retry Location Later" (with same data))  |        
          |<------------------------------------------------|        
          |                                                 |        

     Figure 1. Basic Transaction with 424 and Geolocation-Error Header

     The following subsections provide an initial list of location 
     based errors for any SIP non-100 response, including the new 424 
     (Bad Location Information) response.  These error codes are divided 
     into 5 categories, each based on receiver (of the response) 
     actionable reactions to these errors.  

     o  100 "Cannot Process Location"

     o  200 "Retry Location Later" (with same data)

     o  300 "Retry Location Later" (with device updated location)

     o  400 "Permission Necessary"

     o  500 "Location Information Denial"



  Polk & Rosen              Expires Sept 9, 2009                [Page 14]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     All 5 of the above error codes MUST be implemented to comply with 
     this specification.  Each of these actionable errors is given a 3 
     digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX, 
     and 5XX error codes defined will have the same action expected by 
     X00 categories.  If another action is expected to occur with a newly
     defined error code, it MUST outside the 100-599 range.  100 unit 
     ranges are OPTIONAL for future error codes, but they apply here.


  4.3.1 Location Error: 100 "Cannot Process Location"

     The location error 100 "Cannot Process Location" indicates to a 
     Geolocation-Error recipient that what they supplied in a request, as
     far as location is concerned, cannot be processed at this time.  
     This only has to do with the location that the location "inserter=" 
     added to the request, and not about the overall request that was 
     sent.

     Action(s) to be taken by Geolocation-Error receiver to a 1XX:  
           This error gives no guidance on what to do next.  It is a 
           general information indication to a SIP "inserter=" entity 
           that there was an unspecific problem with the location 
           supplied in the SIP request.

     Implementations MAY choose to react in a way as if this "inserter=" 
     entity received a 2XX or 3XX location error. A 4XX error MUST NOT be
     misunderstood here, as that error category involves human 
     intervention to grant, or not, permission to reveal "inserter=" 
     location when this is likely not desired.

     The text string of "Cannot Process Location" is RECOMMENDED, but not
     mandatory for usage in this error.  Implementations MAY use another 
     text string.

     An example of this location error is here:

     Geolocation-Error: 100; code="Cannot Process Location"; 
                              node="bob.example.com"; 
                              inserter="alice.example.com"; 

     This category covers location errors 1XX; meaning there MAY be more 
     specific errors added to this category in future effort(s).  The 
     same basic actionable reaction is expected by a location "inserter="
     entity to any 1XX location error.


  4.3.2 Location Error: 200 "Retry Location Later" (same data)

     The location error 200 "Retry Location Later" (same data) indicates 
     to a Geolocation-Error recipient that what they supplied in a 
     request, as far as location is concerned, cannot be processed at 
     this time, but to retry this request, without changing the location 


  Polk & Rosen              Expires Sept 9, 2009                [Page 15]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     information, at a later time - in a new SIP request.  It is possible
     that the Location Recipient cannot process location at this time, or
     there was a timeout during dereferencing, if an LbyR were sent.

     Action(s) to be taken by Geolocation-Error receiver to a 2XX: 
           Reactions to a 2XX location error are to try again, without 
           having to update the location supplied originally.  There is 
           no constraints on how long this new try has to wait, unless 
           there is a Retry-After header in a 424 response.

     Implementations SHOULD choose to react by preparing, however this 
     "inserter=" does or can, to queue another message with the same 
     location information, provided the "inserter=" does not move between
     the time of the original request and the transmission time of the 
     new request.  

     Implementations MAY choose whether or not to inform the user of this 
     error.  The text string of "Retry Location Later" is RECOMMENDED, 
     but not mandatory for usage in this error.  Implementations MAY use 
     another text string to inform the user that location was not 
     received by the UAS (i.e., the called party).

     An example of this location error is here:

     Geolocation-Error: 200; code="Retry Location Later"; 
                              node="bob.example.com"; 
                              inserter="alice.example.com"; 

     This category covers location errors 2XX; meaning there MAY be more 
     specific errors added to this category in future effort(s).  The 
     same basic actionable reaction is expected by a location "inserter="
     entity to any 2XX location error.

     If a SIP request has the "routing-allowed" header parameter set to 
     "no", and the SIP server believes processing location within the 
     request in order to service the request properly, a 2XX location 
     error is sent towards the recipient. This error is the proper error 
     even when there is no location in the SIP request, but the SIP 
     request contains a policy statement that location is not to be 
     viewed during transit towards the ultimate destination.


  4.3.3 Location Error: 300 "Retry Location Later" (device updated 
        location)

     The location error 300 "Retry Location Later" (device updated 
     location) indicates to a Geolocation-Error recipient that what they 
     supplied in a request, as far as location is concerned, cannot be 
     processed at this time, but to retry this request, once the location
     information has been updated, in a new SIP request.  

     Action(s) to be taken by Geolocation-Error receiver to a 3XX:  


  Polk & Rosen              Expires Sept 9, 2009                [Page 16]
  Internet Draft         Location Conveyance in SIP              Mar 2009

           3XX location errors indicate the "inserter=" SIP entity needs 
           to refresh its location, or make the location information 
           supplied more complete, without notifying the user of this 
           error.  3XX error are to be solved by without user 
           intervention.

     This document gives no guidance how this is accomplished, given the 
     number of ways a UAC can learn its location, or a SIP intermediary 
     can Sight a UAC, as defined in [RFC3693].

     This 300 location error currently does not indicate what exactly was
     wrong with the location supplied, according to the Location 
     Recipient.  That is left for a future effort.

     Implementations MAY choose whether or not to inform the user of this
     error.  The text string of "Retry Location Later" is RECOMMENDED, 
     but not mandatory for usage in this error.  Implementation MAY use 
     another text string to inform the user that location was not 
     received by the UAS (i.e., the called party).

     A 3XX location error would be used where the Location Recipient 
     cannot find or cannot parse the location supplied, believing that a 
     automated refresh and retry could fix the problem.  Also, a 3XX 
     location error would be used when a Location Recipient did not find 
     any location in a SIP request, but was expecting it.  Perhaps an 
     emergency request was made that did not contain location.  The retry
     in this case would be in the form of an UPDATE Method request, 
     containing location (LbyV or LbyR).

     An example of this location error is here:

     Geolocation-Error: 300; code="Retry Location Later"; 
                              node="bob.example.com"; 
                              inserter="alice.example.com"; 

     This category covers location errors 3XX; meaning there MAY be more 
     specific errors added to this category in future effort(s).  The 
     same basic actionable reaction is expected by a location "inserter="
     entity to any 3XX location error.


  4.3.4 Location Error: 400 "Permission Necessary"

     The location error 400 "Permission Necessary" indicates to a 
     Geolocation-Error recipient that when they sent a particular SIP 
     request, they included location in that request without giving 
     permission in the request for a (or any) SIP server to look at that 
     location information (i.e., the <retransmission-allowed> was set to 
     "no") to route the message at the intended recipient (i.e., the UAS,
     or the called party).  

     Action(s) to be taken by Geolocation-Error receiver to a 4XX:  


  Polk & Rosen              Expires Sept 9, 2009                [Page 17]
  Internet Draft         Location Conveyance in SIP              Mar 2009

           4XX location errors indicate to the UAC (i.e., the calling 
           party) that they need to grant permission to a SIP 
           intermediary server to look at the supplied location to 
           complete the message routing.  This indication MUST require 
           human user intervention, as the rulemaker of the policy on 
           whether or not their location is to be revealed.

     The user of the location "inserter=" device can choose to grant 
     permission to this SIP intermediary server to allow this request to 
     be routed, or the user can deny this location revelation (request by
     the server).  It is the user's choice as rulemaker.  

     Implementations MUST provide the user, as rulemaker, a clear 
     indication that permission to consume their location is sought by an
     entity other than who that user is calling.  The text string of 
     "Permission Necessary" is RECOMMENDED, but not mandatory for usage 
     in this error.  Implementation MAY use another text string to inform
     the user that location is being sought by an intermediary (i.e., not
     the called party).

     This document gives no guidance how this intervention is 
     accomplished, given the number of ways a UAC can accomplish this 
     (i.e., audio prompt or toggle or keystroke on their UA).

     This 400 location error currently does not indicate exactly which 
     SIP server indicates it needs the location revealed.  That said, the
     "node=" FQDN address could be supplied, telling the user (via audio 
     or video indication) which SIP entity wants this location.  Perhaps 
     the user can know in some circumstances whether this is an 
     appropriate "node=" (domain).  All of this is left for a future 
     effort(s).

     An example of this location error is here:

     Geolocation-Error: 400; code="Permission Necessary"; 
                              node="bob.example.com"; 
                              inserter="alice.example.com"; 

     This category covers location errors 4XX; meaning there MAY be more 
     specific errors added to this category in future effort(s).  The 
     same actionable solution is expected to be afforded to the UAC user,
     as rulemaker, to any 4XX location error.


  4.3.5 Location Error: 500 "Location Information Denial"

     The location error 500 "Location Information Denial" indicates to a 
     Geolocation-Error recipient that what they supplied in a request, as
     far as location is concerned, has been denied at this time.  
     This only has to do with the location that the location "inserter=" 
     added to the request, and not about the overall request that was 
     sent.  If this were applied to the SIP request itself, this would 


  Polk & Rosen              Expires Sept 9, 2009                [Page 18]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     equate to a 6XX Global error.  

     Action(s) to be taken by Geolocation-Error receiver to a 1XX:  
           This error gives no guidance on what to do next, other than to
           not try again with this same location supplied.

     If the Location Recipient believed that merely refreshing, or in 
     some other way alter or augment the location supplied would work in 
     a new request, then a 3XX location error SHOULD have been returned 
     (to the "inserter=").  An example of why this 5XX could have been 
     returned is if location were sent as an LbyR, and the LIS denied the
     dereference request from the Location (reference) Recipient, this is
     the expected location error returned to the "inserter=" entity.

     Implementations MUST NOT interpret anything else into this location 
     error other than it is considered a location based denial error.  
     This does not mean the SIP request was denied, or even had an error,
     unless the response was a 424.  Otherwise, this only has to do with 
     the location part of the request.

     The difference between a 1XX and a 5XX location error is simple.  A 
     1XX location error is a case of a Location Recipient either not 
     knowing or not being able to tell the "inserter=" entity what was 
     wrong with the location supplied in a SIP request.  Whereas, a 5XX 
     location error is where the location was purposely, and actively 
     denied (or declined) from being received by the Location Recipient 
     entity, or its user.  This could occur in a UAS or SIP server.

     If implementations choose to inform the UAC user of this error, the 
     text string of "Location Information Denial" is RECOMMENDED, but not
     mandatory for usage in this error.  Implementations MAY use another 
     text string.

     An example of this location error is here:

     Geolocation-Error: 500; code="Location Information Denial"; 
                              node="bob.example.com"; 
                              inserter="alice.example.com"; 

     This category covers location errors 5XX; meaning there MAY be more 
     specific errors added to this category in future effort(s).  The 
     same basic actionable reaction is expected by a location "inserter="
     entity to any 5XX location error.


  4.3.6 Which Scenario Matches Which Error Code?

     The following are some additional failure scenarios, with which 
     error code SHOULD be used for consistency,

     - Scheme (sip:, or sips:, or pres:, or another one) of the LbyR URI 
          isn't supported (100)


  Polk & Rosen              Expires Sept 9, 2009                [Page 19]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     - Format (geo or civic) isn't supported   (100)
     - Cannot parse location  (100)
     - Can't find LIS (no access or no path (100) or denied access(500))
     - Dereference failed (timeout)   (200)
     - Insufficient location info supplied   (300)
     - Cannot find location in message   (300)


  4.4  The 'geolocation' Option Tag  

     This document creates and IANA registers one new option tag: 
     "geolocation".  This option tag is to be used, as defined in RFC 
     3261, in the Require, Supported and Unsupported headers.  Whenever a
     UA wants to indicate support for this SIP extension, the geolocation
     option tag is included in a Supported header of the SIP request.  
     

  4.5 Using sip/sips/pres as a Dereference Scheme

     If an LbyR URI is included in a SIP request, it MUST be a SIP, SIPS
     or PRES-URI.  When PRES: is used, if the resulting resolution, as
     defined in [RFC3856], resolves to a SIP: or SIPS: URI, this 
     section applies.  

     This document IANA registers 3 mandatory to implement URI schemes 
     for LbyR:

        o  SIP:
        o  SIPS:
        o  PRES:

     These 3 are IANA registered in Section 9.6.

     These schemes MUST be implemented according to this document.  
     absoluteURI is not mandatory to implement.

     Dereferencing a Target's location using SIP or SIPS MUST be 
     accomplished by treating the URI as a presence URI and generating a 
     SUBSCRIBE request to a presence server as defined in [RFC3856] 
     using the 'presence' event package.  The resulting NOTIFY will 
     contain a PIDF, which MUST contain a PIDF-LO. See Figure 2. for a 
     basic message flow for a dereference.

     When used in this manner, SIP is a Using Protocol as defined in  
     [RFC3693] and elements receiving location MUST honor the 
     'usage-element' rules as defined in this extension. 








  Polk & Rosen              Expires Sept 9, 2009                [Page 20]
  Internet Draft         Location Conveyance in SIP              Mar 2009

       Alice                 Location Server                      Bob 
         |                                                         |   
         |                  INVITE w/ LbyR URI                     |   
         |-------------------------------------------------------->|   
         |                          |                              |   
         |                       200 (OK)                          |   
         |<--------------------------------------------------------|   
         |                          |                              |   
         |                          |  SUBSCRIBE to LbyR URI       |   
         |                          |<-----------------------------|   
         |                          |  200 (OK)                    |   
         |                          |----------------------------->|   
         |                          |                              |   
         |                          |  NOTIFY   w/ PIDF-LO         |   
         |                          |----------------------------->|   
         |                          |  200 (OK)                    |   
         |                          |<-----------------------------|   
         |                          |                              |   

             Figure 2. Location-by-Reference and Dereferencing

     In Figure 2., Alice sends Bob her location in an LbyR URI.  Bob 
     receives this LbyR URI in the INVITE and generates a new transaction
     (SUBSCRIBE) to retrieve the PIDF-LO of Alice.  If accepted, the 
     PIDF-LO will be in the NOTIFY request from the Location Server back 
     to Bob's UA.  This is the first instance between Alice and Bob that 
     Alice's location is in any message, therefore it is sent only once, 
     from the Location Server to Bob.

     The SUBSCRIBE contains a geolocation option tag in either the 
     Supported or Require header (depending on what strength of support 
     the UAC wants to apply).  The NOTIFY MUST match the subscribing 
     UAC's option-tag strength for geolocation.

     A dereference of an LbyR URI using SUBSCRIBE is not violating a 
     PIDF-LO 'retransmission-allowed' element value set to 'no', as the 
     NOTIFY is the only message in this multi-message set of transactions
     that contains the Target's location, with the location recipient 
     being the only SIP element to receive this PIDF-LO. This is the 
     purpose of this extension to SIP - to convey location to a specific 
     destination.


  5. Geolocation Examples 

     This section contains are two examples of messages providing 
     location.  One shows LbyV with coordinates, the other shows LbyR. 
     The example for (Coordinate format) is taken from [RFC3825]. A 
     civic format example of the same position on the earth as is in the 
     coordinate format example is in appendix B, which is taken from 
     [RFC4776].  The differences between the two formats are within the 
     <gp:location-info> of the examples.  Other than this portion of each


  Polk & Rosen              Expires Sept 9, 2009                [Page 21]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     PIDF-LO, the rest is the same for both location formats.

     The key to the provided samples is in the Geolocation header, which 
     has a different type of URI, based on the different means of 
     location conveyance.  Section 5.1 shows a "cid:" URI, indicating 
     this SIP request contains an LbyV message body - which is in the 
     form of a PIDF-LO.  Section 5.2 shows an LbyR URI indicating 
     location is to be acquired via an indirection dereference mechanism,
     which is determined by the scheme of URI supplied.


  5.1 Location-by-value (Coordinate Format)

     This example shows an INVITE message with a coordinate, or 
     coordinate location.  In this example, the SIP request uses a 
     sips-URI  [RFC3261], meaning this message is TLS protected on a 
     hop-by-hop basis all the way to Bob's domain.

     INVITE sips:bob@biloxi.example.com SIP/2.0
     Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
     Max-Forwards: 70
     To: Bob <sips:bob@biloxi.example.com>
     From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl 
     Call-ID: 3848276298220188511@atlanta.example.com
     Geolocation: <cid:target123@atlanta.example.com> 
       ;inserted-by="alice@atlanta.example.com" 
     Supported: geolocation 
     Accept: application/sdp, application/pidf+xml
     CSeq: 31862 INVITE
     Contact: <sips:alice@atlanta.example.com>
     Content-Type: multipart/mixed; boundary=boundary1
     Content-Length: ...

     --boundary1

     Content-Type: application/sdp

     ...SDP goes here

     --boundary1

     Content-Type: application/pidf+xml
     Content-ID: <target123@atlanta.example.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:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
            xmlns:gml="http://www.opengis.net/gml"
            entity="pres:alice@atlanta.example.com">
          <dm:device id="point2d">
           <timestamp>2007-12-02T14:00:00Z</timestamp>


  Polk & Rosen              Expires Sept 9, 2009                [Page 22]
  Internet Draft         Location Conveyance in SIP              Mar 2009

           <status>
            <gp:geopriv>
              <gp:location-info>
                <gml:location>
                  <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                    <gml:pos>33.001111 -96.68142</gml:pos>
                  </gml:Point>
                 </gml:location>
              </gp:location-info>
              <gp:usage-rules>
                <gp:retransmission-allowed>no</gp:retransmission-allowed>
                <gp:retention-expiry>2007-12-07T18:00:00Z</gp:retention-
                              expiry>
              </gp:usage-rules>
              <gp:method>DHCP</gp:method>
              <gp:provided-by>www.example.com</gp:provided-by>
            </gp:geopriv>
           </status>
          </dm:device>
        </presence>
     --boundary1--

     The Geolocation header field from the above INVITE...

        Geolocation: <cid:target123@atlanta.example.com>

     ...indicates the content-ID location [RFC2392] within the multipart 
     message body of where location information is, with SDP being the 
     other message body part.  The "cid:" eases parsing of message 
     bodies.

     If the Geolocation header field were this instead:

        Geolocation: <sips:server5.atlanta.example.com/target123>

     ...the presence of something other than "cid:" indicates an LbyR is 
     included in this message.  It is expected that any node wanting to 
     know where user target123 is would subscribe to server5 to 
     dereference the sips-URI (see Figure 2. for this message flow, and 
     Section 5.2 for this decoded example). The returning NOTIFY would 
     contain Alice's location in a PIDF-LO, as if it were included in a 
     message body  (part) of the original INVITE here.  


  5.2 Location-by-reference

     Below is an INVITE request with an LbyR URI instead of an LbyV 
     PIDF-LO message body part shown in Section 5.1.  It is up to the 
     location recipient to dereference Alice's location at the Atlanta 
     LIS server containing the location record.  Dereferencing, if done 
     with SIP, is accomplished by the Location Recipient sending a 
     SUBSCRIBE request to the URI reference for Alice's location.  The 


  Polk & Rosen              Expires Sept 9, 2009                [Page 23]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     received NOTIFY is the first SIP request containing Alice's UA 
     location, as a PIDF-LO message body (see Figure 2 for this message 
     flow example). The NOTIFY, in this case, is the SIP request that is 
     conveying location, and not the INVITE.  There is no retransmission 
     of location in this usage.

     INVITE sips:bob@biloxi.example.com SIP/2.0
     Via: SIP/2.0/TLS pc33.atlanta.example.com
       ;branch=z9hG4bK74bf9
     Max-Forwards: 70
     To: Bob <sips:bob@biloxi.example.com>
     From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl 
     Call-ID: 3848276298220188511@atlanta.example.com
     Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>
       ;inserted-by="bigbox3.atlanta.example.com" 
     Supported: geolocation 
     Accept: application/sdp, application/pidf+xml
     CSeq: 31862 INVITE
     Contact: <sips:alice@pc33.atlanta.example.com>

     (...SDP goes here as the only message body)

     A Location Recipient would need to dereference the sips-URI in the 
     Geolocation header field to retrieve Alice's location.  If the 
     atlanta.example.com domain chooses to implement location conveyance 
     and delivery in this fashion (i.e., LbyR), it is RECOMMENDED that 
     entities outside this domain be able to reach the dereference 
     server, otherwise this model of implementation is only viable within
     the atlanta.example.com domain.  

  6.  SIP Element Behavior 

     Because a device's location is generally considered to be sensitive 
     in nature, location information needs to be protected when 
     transmitted.  This can be addressed through securing the location 
     information to prevent either viewing or changing the PIDF-LO.

     Section 26 of [RFC3261] defines the security functionality SIPS by 
     transporting SIP messages with either TLS or IPSec protection 
     between SIP entities.  

     If a SIP entity wants to prevent all SIP entities in a request path 
     from viewing or just changing the contents of the PIDF-LO, save 
     those that possess decryption key, the message body needs to be 
     secure by a means such as S/MIME.  This would be the case in which a
     UAC wants to make sure only the destination UAS can read the 
     PIDF-LO. S/MIME can be used for just signing, and not encrypting, a 
     PIDF-LO message body to ensure the integrity of the PIDF-LO is 
     maintained.





  Polk & Rosen              Expires Sept 9, 2009                [Page 24]
  Internet Draft         Location Conveyance in SIP              Mar 2009

  6.1 UAC Behavior

     A UAC can send location in a SIP request, either because it is 
     expected to facilitate location-based routing of the request, or 
     spontaneously (i.e., a purpose not defined in this document but 
     known to the UAC).  Alice communicating her location to Bob in a SIP
     request is a simple example of this.  If Alice wanted to include her
     location as a message body in an INVITE that also has an SDP message
     body, the Content-Type: Multipart MUST be supported by both UAC and 
     UAS.  Multipart comes in many forms (/mixed, /alternative, etc), and
     this document does not limit which type of Multipart is used, though
     future documents MAY specify or limit Multipart to a subset of all 
     the choices for a given use.

     A UAC conveying location MUST include a locationValue in a 
     Geolocation header (see section 4.1) with either an LbyV indication 
     (a cid-URL), or an LbyR.  An LbyV message body sent without a 
     Geolocation header field MUST NOT occur.  The UAC supporting this 
     extension MUST include a Supported header with the 'geolocation'
     option tag.

     More than one location format (civic and coordinate) can be included
     in the same message body part, but all location parts of the same 
     PIDF-LO MUST point at the same position on the earth, identifying 
     the same target.  The same location in multiple formats, for 
     example, a partial or complete geodetic and a partial or complete 
     civic, can allow the recipient to use the most convenient or 
     preferable format for its use.  

     Multiple PIDF-LOs are allowed in the same request, with each allowed
     to point at separate positions - however, each PIDF-LO MUST identify
     a different Target.  Therefore, there will be no confusion by a 
     Location Recipient receiving more than one PIDF-LO (in a message 
     body or when dereferenced, or a combination).  It is RECOMMENDED 
     there is only one locationValue in a single SIP request for the same
     Target.  More than one will likely lead to confusion by a Location 
     Recipient because this extension does not provide guidance on what a
     recipient is to do with more than one location, nor does it give any
     preference regarding which location is better or worse than another 
     location in the same request.

     The 'geolocation' option tag is inserted in a Supported header by a 
     UAC to provide an indication of support for this extension.  The 
     presence of the 'geolocation' option tag in a Supported header 
     without a Geolocation header field in the same message informs a SIP
     element receiving this request that the UAC understands this 
     extension, but it does not know or wish to convey its location at 
     this time.  Certain scenarios exist (location-based retargeting) in 
     which location is required in a SIP request in order to retarget the 
     message properly.  This affects how a UAS or SIP server processes 
     such a request.



  Polk & Rosen              Expires Sept 9, 2009                [Page 25]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     The 'geolocation' option tag SHOULD NOT be used in the Proxy-Require 
     Header, because the UAC often will not know the underlying topology 
     to know which proxy will do the retargeting, thus increasing the 
     likelihood of a request failure by the first hop proxy that does not
     understand this extension, but is required to by inclusion of the 
     option tag in this header.

     A UAC inserting a locationValue MUST include an "inserted-by=" 
     parameter to indicate its hostport.  This is copied to the 
     "inserter=" parameter of the Geolocation-Error header in a response 
     if a Location Recipient determines there is something wrong with the
     locationValue in this request.  Because more than one locationValue 
     can be inserted along the path of the request, this indication is 
     necessary to show which locationValue had the problem in the 
     response, and who the locationErrorValue is for.  For example:

     Geolocation: <cid:alice123@atlanta.example.com>; 
                   inserted-by="alice@atlanta.example.com"

     If a UAC does not learn and store its location locally (a GPS chip) 
     or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR 
     URI (from DHCP for example).  If the latter is the case, the UAC MAY
     SUBSCRIBE to this LbyR URI, using the 'presence' event package, to 
     get and store its own location.  

     The act of dereferencing a Target's LbyR will be challenged by the 
     LIS where this location record is - providing a good deal of 
     protection, SHOULD still be treated as equivalent to possession of 
     the location information itself and thus TLS SHOULD be used when 
     transmitting LbyR hop-by-hop along the path to the Location 
     Recipient, for protection reasons.  This is not to be confused with 
     a possession model, in which possessing the LbyR grants 
     authorization to dereference the URI.  Any entity dereferencing the 
     LbyR MUST pass whatever authentication and authorization rules are 
     on the LIS for this location record.  The Ruleholder from [RFC3693] 
     is still very much in control - for any entity possessing the LbyR.

     If the Location Generator wishes to control whether any location 
     included in the SIP request or added along the signaling path of 
     this request can be viewed for routing decisions, the Location 
     Generator adds a Geolocation header value including the 
     "routing-allowed=no" parameter.  This header parameter provides 
     specific policy rules for each locationValue (if there is more than 
     one inserted along the signaling path) within the SIP request.  A 
     UAC SHOULD include the "routing-allowed" header parameter, with or 
     without a locationValue, to each SIP request supporting this 
     specification to ensure the UAC's policy for intermediaries which 
     might add a locationValue of the Target downstream.  The UAC 
     understands that the default behavior for SIP servers is to consider
     this value to be present, and that it is set to "no".

     The UAC MUST understand there is no feedback mechanism to inform the


  Polk & Rosen              Expires Sept 9, 2009                [Page 26]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     Target if a SIP server has included a locationValue downstream.

     If a UAC has already conveyed location in the original request of a 
     transaction, and wants to update its location information (for 
     whatever reason) after the original request is sent, or after a 
     dialog is created (regardless of how the UAC conveyed location 
     previously, as an LbyV or LbyR) - this is done by a UAC sending an 
     UPDATE request [RFC3311] containing the geolocation option tag and 
     Geolocation header with the new locationValue (LbyV or LbyR) to the 
     original destination UAS.

     A PIDF includes identity information.  It is possible for the 
     identity in the PIDF to be anonymous.  Implementations of this 
     extension SHOULD consider the appropriateness of including an 
     anonymous identity in the location information where a real identity
     is not required.  When using LbyR, the LbyR MUST NOT contain any 
     user identifying information. For example, use something 
     unidentifiable like

        3fg5t5yqw@example.atlanta.com 

     rather than 

        aliceishere@example.atlanta.com).

     Use of self-signed certificates is inappropriate for use in 
     protecting a PIDF, as the sender does not have a secure identity of 
     the recipient.


  6.1.1 UAC Receiving a Location Failure Indication

     Location Recipients can be either, or both, destination UASs and 
     intermediate servers that use the location information for 
     location-based routing decisions.  If a sent request fails based on 
     the location information in the request, a 424 (Bad Location 
     Information) response is sent back to the UAC.  The 424 MUST have a 
     Geolocation-Error header containing one or more locationErrorValues 
     in the response message.  A locationErrorValue has a header 
     parameter indicating which entity inserted the locationValue 
     correlated to this error, called the "inserter=" parameter.  This 
     "inserter=" parameter (in the locationErrorValue) is copied from the
     "inserted-by=" parameter (from the locationValue) by the Location 
     Recipient (UAS or proxy) sending the error response.  A UAC 
     receiving a Geolocation-Error in any response type MUST review the 
     "inserter=" parameter in the locationErrorValue to see if it 
     indicates this UAC.  If locationErrorValue does not match, the 
     locationErrorValue MUST be ignored. If a locationErrorValue is in a 
     424, and the "inserter=" entity is not this UAC, the response SHOULD
     be treated as a 400 response.  If locationErrorValue does indicate 
     this UAC, this UAC MUST process the response, including the 
     Geolocation-Error code  (defined in section 4.3).  Further, UAC MUST


  Polk & Rosen              Expires Sept 9, 2009                [Page 27]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     ignore a Geolocation-Error header value, even for this UAC, even in 
     a 424 response if the UAC did not include a Geolocation header value
     (with locationValue) in the request part of the transaction.

     A UAC MAY reattempt a new request if it believes it can correct the 
     stated failure in the Geolocation-Error header, unless the location 
     error is a 5XX level error - which clearly states in Section 4.3 not
     to do this.  A UAC MUST follow all the guidance that pertains to 
     UACs from Section 4.3 (Geolocation-Error header), heeding what to do
     in case it receives any of the error codes articulated in that 
     section.

     Any UAC that inserted location into a request SHOULD be prepared to 
     receive the Geolocation-Error header in any response, looking to 
     determine if a locationErrorValue is meant for the UAC, and to react 
     accordingly.

     If a UAC includes location in a request, and either the UAS does not
     determine errored location was critical to the transaction and 
     accept the request, or the request failed for reason other than 
     location, any response MAY contain a Geolocation-Error header 
     containing a locationErrorValue with the details of the location 
     error.


  6.2 UAS Behavior

     If the Geolocation header field is present in a received SIP 
     request, the type of URI contained in the locationValue will 
     indicate if location is an LbyV in a message body (part) or LbyR, 
     requiring an additional dereference transaction.  If the LbyR URI is
     sip:, sips: or pres:, and the UAS wants to learn the UAC's location,
     the UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve 
     the PIDF-LO being conveyed by the UAC as defined in  [RFC3856].  If 
     successful, the PIDF-LO will be returned in the NOTIFY request from 
     the remote host.  The UAS is not REQUIRED to dereference the LbyR if
     it does not want to (by configuration or user choice).  It is 
     RECOMMENDED the UAS render the location sent to it, however it is 
     configured to do so.

     A Require header with the 'geolocation' option tag indicates the 
     UAC is requiring the UAS understand this extension or else send 
     an error response.  A 420 (Bad Extension) with a 'geolocation' 
     option tag in an Unsupported header would be the appropriate 
     response in this case.

     It is possible, but undesirable, for a message to arrive with a body
     containing an LbyV, but with no Geolocation header field value 
     pointing to it (potentially no Geolocation header field at all). In 
     this case, the recipient MAY still read and use the message body. 
     Unless stated otherwise by future standards-track publication(s), a 
     LbyR URI only has meaning within the Geolocation header field and 


  Polk & Rosen              Expires Sept 9, 2009                [Page 28]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     MUST NOT appear in any other SIP header field.

     There are 2 Geolocation header parameters, 

        o "inserted-by="
        o "used-for-routing"

     The "inserted-by=" parameter informs a Location Recipient which SIP 
     element added this locationValue to the SIP request.  This parameter
     is mandatory for each locationValue in the request.  The value in 
     the "inserted-by=" parameter is copied into the "inserter=" 
     parameter in each locationErrorValue if there is an error in the 
     location to be reported back to the location sender.  See section 
     6.2.1.

     The "used-for-routing" parameter is included in the locationValue if
     a SIP server used the location in the request to determine how to 
     route or forward the message towards the ultimate destination.  If 
     there are more than one locationValues in the Geolocation header, 
     and it is possible that different locationValues were used to route 
     the message at different times of this request's journey.  This is 
     allowed, as it is consistent with the rule that anytime a message is
     routed based upon a locationValue, a "used-for-routing" parameter is
     added to the applicable locationValue.  This parameter should be 
     present in each locationValue used along the path.  A 
     "used-for-routing" parameter MUST NOT ever be removed from a 
     locationValue in a request.

     Additional locationValues inserted into a request SHOULD be placed 
     the order they were generated, and not rearranged.  This informs a 
     Location Recipient which was the last locationValue in the message 
     that was used to route the message.  This is for troubleshooting and
     management reasons.

     Individual header parameters in any received locationValue MUST NOT 
     be modified or deleted in transit to the ultimate destination.

     A UAS MUST NOT send location in a response message, as there can be 
     any number of issues/problems with receiving location, and the UAC 
     or proxy servers cannot error a response.  Therefore, the UAS, if it
     wants to send a UAC its location, SHOULD do so in a new request in a
     separate transaction.  This document gives no guidance which SIP 
     request to use, but SIP MESSAGE is a viable choice.

     A UAS MAY include a 'geolocation' option tag in the Supported header 
     of a response, indicating it does understand this extension, even if
     location was not in a request to the UAS.

     A UAS wishing to dereference an LbyR URI contained in a received 
     request will use the 'presence' event package in a SUBSCRIBE request
     to the URI.  If accepted, the PIDF-LO will return to the UAS in a 
     NOTIFY request.  If there are any errors during dereferencing, or in


  Polk & Rosen              Expires Sept 9, 2009                [Page 29]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     the PIDF-LO itself, the UAS will error the original request to the 
     UAC with a locationErrorValue indicating what the UAS concluded was 
     wrong with the location.  This is to include any dereferencing 
     problems encountered.

     Section 4.5 of this document called for the IANA registration of 3 
     URI schemes (sip:, sips:, and pres:) that are mandatory to implement
     for dereferencing.  

     A UAS MUST be prepared to receive subsequent location updates from 
     the UAC, either LbyV or LbyR (regardless of how the UAS received 
     location previously from this UAC).  The UAC will convey location 
     using the UPDATE [RFC3311] method to the UAS.

     If there is more than one location (any combination of LbyV and 
     LbyR), this document does not give guidance what a Location 
     Recipient does with each location.  There are no priority or 
     more-trusted indications given by this document. All this is 
     considered application specific, and out-of-scope of this document. 
     This document makes it clear that if when there are more than one 
     location, each in the same PIDF-LO MUST be about the same Target 
     (identifier) and point at the same position on the earth.  If there 
     is more than one PIDF-LO with different Target identifiers, then 
     the UAC is merely telling the UAS where more than one Target is, and
     there should not be any conflict.


  6.2.1 UAS Generating a Location Failure Indication

     If a UAS receives location in a request, but determines there is a 
     problem with the location in the request, it is the responsibility 
     of the UAS to inform whomever inserted location into that request 
     there was a problem experienced.  The Geolocation header in the 
     request has a locationValue, providing the UAS a URI indicating 
     where the Target's location is. The Location Target identified in 
     the PIDF-LO may or may not be the location inserter, or the 
     generator of the request (the UAC or SIP server).  Ultimately, 
     location is in a PIDF-LO.  This is either in the request as a 
     message body (LbyV), or it has to be dereferenced from the LbyR in 
     the locationValue in the request.  LbyR records are typically kept 
     on a LIS, which can challenge all dereference requests.  All 
     PIDF-LOs have a Location Target identifier.  This is who the 
     location is about.  The "inserted-by=" parameter of the 
     locationValue tells the UAS who inserted that locationValue.  This 
     "inserted-by=" parameter is copied into the "inserter=" parameter of
     the locationErrorValue generated by the Location Recipient (the 
     UAS), in a response, when it wants to inform the location 
     "inserter=" entity there was a problem with the location it 
     received.  

     There can be more than one locationValues in a request.  The 
     "inserter=" parameter in the locationErrorValue will distinguish it 


  Polk & Rosen              Expires Sept 9, 2009                [Page 30]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     from being misunderstood by entities that did not insert the errored
     location.  

     If there is one valid locationValue in a request, even if all the 
     others have errors with them, a 424 (Bad Location Information) 
     response MUST NOT be sent.  The Location Recipient (the UAS) is 
     RECOMMENDED to send a locationErrorValue for each errored 
     locationValue, with unique "inserter=" parameters to make sure the 
     right entities know which locations were in error.

     As hinted at, a location "inserter=" can be a UAC or it can be an 
     in-signaling-path SIP server, who is acting as a UAC Sighter, as 
     defined in RFC3693.  This means the SIP server is including its 
     version of where it thinks the UAC is, geographically.  This 
     "inserter=" has to be in the form of an LbyR URI in a locationValue, 
     because SIP servers are not allowed to insert message bodies, as of 
     the time of this publication, from all the way back to RFC3261.

     Each locationErrorValue has a error code, letting the location 
     "inserter=" entity know what was wrong with the location supplied. 
     See Section 4.3 for the 5 actionable responses a UAC can take from 
     a locationErrorValue.  

     If the location "inserted-by=" entity, meaning either the UAC or 
     proxy in the message path, chose to indicate that location was so 
     important in the request to include a 'geolocation' option tag in a 
     Require header, the response SHOULD be a 424 (Bad Location 
     Information) back to the "inserter=" entity (knowing the response 
     will ultimately go to the UAC regardless) if there needs to be a 
     locationErrorValue sent because the location was bad.  Only entities
     identified in a locationErrorValue as the "inserter=" entity will 
     pay attention to this locationErrorValue.  All other entities MUST 
     ignore any locationErrorValue not directed towards them.  See 
     section 4.3 for more information on this, including all the location
     specific errors and Geolocation-Error header parameters.  

     In the above scenario ('geolocation' option tag in a  Require 
     header), the only other response can be a 420, but only if the UAS 
     does not support this Geolocation extension to SIP, else the 424 is 
     sent.
     If the location "inserted-by=" entity placed the 'geolocation' 
     option tag in a Supported header, the response can be a 424 if it 
     chooses, but also can be any other SIP response, including a 200 
     OK.  A locationErrorValue in a Geolocation-Error header that is not 
     in a 424 (Bad Location Information) response is considered 
     informational by the Location Recipient, and not considered 
     important enough to reject the request based solely on bad location 
     information.

     For example, Alice INVITEs Bob to a dialog, and includes geolocation 
     in the request. Bob can accept the INVITE with a 200 OK and still 
     add a locationErrorValue in the 200 OK indicating "yes, I accept 


  Polk & Rosen              Expires Sept 9, 2009                [Page 31]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     your request, and btw, something was wrong with the location you 
     provided (in the INVITE)".  What was wrong with the location is 
     indicated by the Geolocation-Error code.  Who this 
     locationErrorValue is for is indicated by the "inserter=" parameter.

     Each locationErrorValue is destined for one "inserter=" entity.  
     This gives a Location Recipient one mechanism to tell each inserter 
     what the Location Recipient concluded was wrong with what the 
     "inserter=" included (as far as location is concerned).  Therefore, 

     o  there MUST be a locationErrorValue for each locationValue that 
        was considered bad by the UAS to ensure each upstream location 
        inserter understands which error code(s) is intended for them 
        (and which to ignore).

     o  there MUST NOT be more than one locationErrorValue in the 
        response per locationValue in the request.  

     o  there MUST NOT be more than one locationErrorValue to the same 
        "inserter=" in the request.  

     o  there MUST NOT be a locationErrorValue in the response for a 
        locationValue in the request that was not in error, according to 
        the Location Recipient.  

     Here is an example of a Geolocation-Error header

     Geolocation-Error: 400; code="Permission Necessary"; 
                             node="server42.example2.com"; 
                             inserter="alice.example.com"; 

     The above example says that the Location Recipient is 
     server42.example.com, and this entity believes it cannot route this 
     message without knowing the "inserter="'s location.  This location 
     may be in the request, or it may need to be in the request and was 
     not.  If location is encrypted, server42 doesn't know it is in the 
     request.  server42.example.com sends a 424 (Bad Location 
     Information) response with a locationErrorValue indicating a 400 
     location error, which means it requires permission to view Alice's 
     location to proceed with processing her signaling.  Section 4.3 
     highlights this example, stating the user, Alice, MUST be made aware
     of this location revelation request.  This document does not give 
     any guidance how Alice is to be informed (i.e., audio, visual, 
     etc).  Alice can grant permission or choose not to, knowing this SIP
     request attempt (to this destination, at this time) will fail.  The 
     problem could be corrected if a future SIP request were to travel 
     through a different server than server42 (or it might not).

     See Section 4.3 for further rules about the Geolocation-Error header
     and the locationErrorValue.   

     This document says nothing about what a Location Recipient does with


  Polk & Rosen              Expires Sept 9, 2009                [Page 32]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     more than one 'good' locationValue in a request (i.e., which to 
     choose to use).  This scenario MAY be addressed in a future effort.

     Further, more than one error code is allowed in the 
     locationErrorValue - each having one "inserter=" parameter.  The 
     error codes destined for the same inserter MUST NOT contradict the 
     meaning of the problem the Location Recipient had with a particular 
     locationValue. 


  6.3 Proxy Behavior

     [RFC3261] states message bodies cannot be added by proxies.  
     However, proxies are permitted to add a header to a request.  This 
     implies that a proxy can add a Geolocation locationValue with 
     LbyR URI, but not LbyV message body.  

     It is allowed, but NOT RECOMMENDED, for more than one SIP element to
     insert location into a request along its path.  As described earlier
     in this document, each insertion of location into a SIP request is 
     accompanied by a new locationValue in a Geolocation header.  Also 
     described earlier, each locationValue MUST contain an "inserted-by="
     value indicating to a Location Recipient which host inserted 
     location into a particular request.  

     However, if location is already in a SIP request, a SIP server 
     SHOULD NOT add another LbyR that identifies the same target in the 
     PIDF-LO (in the <dm:device id> element) to the same request.  This 
     will likely cause confusion at the Location Recipient as to which to
     use.

     A proxy is permitted to read any locationValue, and the associated 
     body, if not S/MIME protected, in transit if present, and can use 
     the contents of the header field to make location-based retargeting
     decisions, if retargeting requests based on location is a function 
     of that proxy.  Retargeting is defined in [RFC3261].  However, if 
     the Geolocation header parameter "routing-allowed" is present and 
     set to "no", or is not present (knowing the default behavior is "no"
     if not present, with or without a Geolocation header), SIP servers 
     MUST NOT view the contents of the LbyV message body. Further, SIP 
     servers MUST NOT attempt to dereference an LbyR.  This is because 
     the SIP request, likely from the originating UAC did not give the 
     SIP server permission to view the location within the SIP request.

     If the Geolocation header parameter "routing-allowed" is present in 
     a SIP request, the value MUST NOT be changed during processing of 
     the request.  If the Geolocation header parameter "routing-allowed" 
     is not present, SIP servers are to treat the location within the 
     request as if the header parameter "routing-allowed" were present 
     and set to "no".

     In the spirit of informing implementers of B2BUAs and SBCs, each 


  Polk & Rosen              Expires Sept 9, 2009                [Page 33]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     server type really should adhere to the above proxy guidance with 
     respect to the "Routing-allowed" header parameter, understanding 
     that there are no IETF police, and the specific behaviors of these 
     types of SIP servers cannot presently be defined. In other words, if
     the particular type of SIP server mentioned here is not the ultimate
     destination of this SIP request and supports this SIP extension, 
     each policy rule within the Geolocation header needs to remain 
     intact and unchanged.

     No type of SIP server can delete a "Routing-allowed" header 
     parameter, but if one is not yet present, any SIP server MAY add a 
     "Routing-allowed" header parameter with the value set to "no" only.

     More than one Geolocation locationValue in a message is permitted, 
     but can cause confusion at the recipient.  If a proxy chooses to add
     a locationValue to a Geolocation header, which would be a local 
     policy decision, the new locationValue MUST be added to the end of 
     the header (after previous locationValue(s)).  This is done to 
     create an order of insertion of locationValues along the path.  
     Proxies MUST NOT modify the order of locationValues in a geolocation
     header.  

     A proxy wishing to dereference an LbyR URI contained in a received 
     request will use the 'presence' event package in a SUBSCRIBE request
     to the URI.  If accepted, the PIDF-LO will return to the proxy in a 
     NOTIFY request.  If there are any errors during dereferencing, or in
     the PIDF-LO itself, the proxy will error the original request to the
     UAC with a locationErrorValue indicating what the proxy concluded 
     was wrong with the location.  This is to include any dereferencing 
     problems encountered.


  6.3.1 Proxy Behavior with Geolocation Header Parameters

     SIP servers MUST NOT delete any existing Geolocation locationValue
     (URI or header parameter) from a request.  An existing locationValue
     (URI or header parameter) MAY only be modified by adding a 
     "used-for-routing" parameter to an existing locationValue, if the 
     request was retargeted based on the location within that 
     locationValue.  Further modification of this Geolocation header 
     field MUST NOT occur.  For example, an existing Geolocation 
     locationValue in a request of:

     Geolocation: <cid:alice123@atlanta.example.com>; 
                   inserted-by="alice123@atlanta.example.com"; 

     can be modified by a proxy to add the "used-for-routing" parameter, 
     like this:

     Geolocation: <cid:alice123@atlanta.example.com>; 
                   inserted-by="alice123@atlanta.example.com"; 
                   used-for-routing


  Polk & Rosen              Expires Sept 9, 2009                [Page 34]
  Internet Draft         Location Conveyance in SIP              Mar 2009


     if this is the locationValue the proxy used to make a retargeting 
     decision based upon, but make no other modification.

     A SIP server MAY add a new Geolocation locationValue to a SIP 
     request.  The proxy SHOULD NOT insert a locationValue of a Location 
     Target unless it is reasonably certain it knows the actual location 
     of the Location Target, for example, if it thoroughly understands 
     the topology of the underlying access network and it can identify 
     the device reliably (in the presence of, for example, NAT or VPN).  
     Routing errors are likely if the SIP server inserts an incorrect 
     locationValue.

     A server adding a locationValue to an existing Geolocation header 
     would look like:

   Geolocation: <cid:alice123@atlanta.example.com>; 
                 inserted-by="alice123@atlanta.example.com",
                <sips:3sdefrhy2jj7@lis1.atlanta.example.com>; 
                 inserted-by="lis1.atlanta.example.com" 

     Notice the locationValue added by the proxy is last among 
     locationValues.  This practice MUST be done for all added 
     locationValues.

     If this request was then retargeted by an intermediary using the 
     locationValue inserted by the server, the intermediary would add a 
     "used-for-routing" parameter like this:

   Geolocation: <cid:alice123@atlanta.example.com>;
                 inserted-by="alice123@atlanta.example.com",
                <sips:3sdefrhy2jj7@lis1.atlanta.example.com>; 
                 inserted-by="lis1.atlanta.example.com"; used-for-routing

     It is conceivable that an initial routing decision is made on 
     one locationValue, and subsequently another routing decision is 
     made on a different locationValue further towards the ultimate 
     destination.  This retargeting decision can be made on a newly 
     inserted locationValue.  While unusual, it can occur.  In such a 
     case, proxies MUST NOT remove any existing "used-for-routing" header
     parameter.  In this instance, the SIP server retargeting based on 
     another locationValue MUST add the "used-for-routing" header 
     parameter to the locationValue used for retargeting by this server. 
     This will result in a Geolocation header looking as if it were 
     retargeting more than once, which would be true - and is the desired
     outcome.

     A Proxy that inserts or adds locationValue into a request MAY move a
     'geolocation' option that is in a Supported header into a Require 
     header if this proxy deems geolocation to be that important to 
     Location Recipient(s) of this request.



  Polk & Rosen              Expires Sept 9, 2009                [Page 35]
  Internet Draft         Location Conveyance in SIP              Mar 2009


  6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues

     For proxies that receive a SIP request that contains a location 
     error, either in a contained message body or after the proxy does a 
     dereference of the LbyR URI, all the rules applicable to a UAS apply
     here  (see Section 6.2.1.), since in this case, the proxy is 
     considered a Location Recipient. Therefore, there is no reason to 
     restate them here, and potentially have the two sections be 
     inconsistent.  The one thing to add is that a proxy does not need to
     examine location contained in a request. Section 6.2.1. only applies
     to proxies that are needing, monitoring or policing location within 
     requests (for whatever reason).

     If a proxy inserted a locationValue into a request, it SHOULD be 
     ready to examine the response to that request, in case there is one 
     or more location errors in the response.  To a great degree, this 
     scenario has the proxy behaving as a UAC (see section 6.1.1.) that 
     included a locationValue a request, which then receives an error to 
     that locationValue.  

     This location inserting proxy SHOULD be transaction stateful for the 
     response.  If the proxy is configured as a stateless proxy, and it 
     inserts location, it MUST process and monitor all SIP responses, 
     looking for locationErrorValues that indicate it was the "inserter="
     to learn that location it supplied was in error.  It SHOULD react 
     accordingly to the error code received.  This document gives no 
     guidance what the proxy should do to rectify the bad location 
     information, but a future document MAY address this.  


  7.  Geopriv Privacy Considerations

     Location information is considered by most to be highly
     sensitive information, requiring protection from eavesdropping, 
     and altering in transit.  [RFC3693] articulates rules to 
     be followed by any protocol wishing to be considered a "Using 
     Protocol", specifying how a transport protocol meets those rules. 
     This section describes how SIP as a Using Protocol meets those 
     requirements.

     Quoting requirement #4 of [RFC3693]:

     "The Using Protocol has to obey the privacy and security 
      instructions coded in the Location Object and in the 
      corresponding Rules regarding the transmission and storage 
      of the LO."

     This document requires that SIP entities sending or receiving 
     location MUST obey such instructions.

     Quoting requirement #5 of [RFC3693]:


  Polk & Rosen              Expires Sept 9, 2009                [Page 36]
  Internet Draft         Location Conveyance in SIP              Mar 2009


     "The Using Protocol will typically facilitate that the keys 
      associated with the credentials are transported to the 
      respective parties, that is, key establishment is the 
      responsibility of the Using Protocol."

     [RFC3261] and the documents it references define the key 
     establishment mechanisms.

     Quoting requirement #6 of [RFC3693]:

     "(Single Message Transfer)  In particular, for tracking of 
      small Target devices, the design should allow a single 
      message/packet transmission of location as a complete 
      transaction."

     When used for tracking, a simple NOTIFY or UPDATE normally is 
     relatively small, although the PIDF itself can get large.  Normal 
     RFC 3261 procedures of reverting to TCP when the MTU size is 
     exceeded would be invoked.


  8.  Security Considerations

     Conveyance of physical location of a UAC raises privacy concerns, 
     and depending on use, there probably will be authentication and 
     integrity concerns.  This document calls for conveyance to normally 
     be accomplished through secure mechanisms, like S/MIME protecting 
     message bodies (but this is not widely deployed) or TLS protecting 
     the overall signaling.  In cases where a session set-up is 
     retargeted based on the location of the UAC initiating the call or 
     SIP MESSAGE, securing the LbyV location with an end-to-end 
     mechanism such as S/MIME is problematic, because one or more proxies
     on the path need the ability to read the location information to 
     retarget the message to the appropriate new destination UAS.  
     Securing the location hop-by-hop, using TLS, protects the message 
     from eavesdropping and modification, but exposes the information to 
     all proxies on the path as well as the endpoint.  In most cases, the
     UAC does not know the identity of the proxy or proxies providing 
     location-based routing services, so that end-to-middle solutions 
     might not be appropriate either. 

     These same issues exist for basic SIP signaling, but SIP normally 
     does not carry information to physically track a user; making this 
     extension especially sensitive.

     When location is inserted by a UAC, which is RECOMMENDED, it can 
     decide whether to reveal its location using hop-by-hop methods.  UAC
     implementations MUST make such capabilities conditional on explicit 
     user permission, and SHOULD alert a user that location is being 
     conveyed.  Proxies inserting location for location-based routing are
     unable to meet this requirement, and such use is NOT RECOMMENDED.  


  Polk & Rosen              Expires Sept 9, 2009                [Page 37]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     Proxies conveying location using this extension MUST have the 
     permission of the Target to do so.  

     One facet within this extension is such that locations can be placed
     on a remote server, accessible with the possession of a URI.  The 
     concept of an LbyR URI has its own security considerations.  It is 
     tempting to assume that the dereference would have authentication, 
     authorization and other security mechanisms that limit the access to
     information.  Unfortunately, this might not be true.  The access 
     network the UAC is connected to can be the source of location 
     reference, and it might not have any credentialing mechanism 
     suitable for controlling access to location.  Consider, 
     specifically, a nomadic user connected to an access network in a 
     hotel.  The UAC has no way to provide a credential acceptable to 
     the hotel Location Server (LS) to any of its intended Location 
     Recipients.  The recipient of a reference does not know if a 
     reference has appropriate authorization policies or not.  The LS 
     should provide location to any requestor.

     Accordingly, possession of the reference should be considered 
     equivalent to possession of the value, and the reference should be 
     treated with the same degree of care as the value.  Specifically, 
     TLS MUST be used to protect the security of the reference.  Notice 
     that this does not constrain the dereference protocol to use TLS. 
     That specification is left entirely to the dereferencing protocol 
     documents.

     There is no integrity on any locationValue or locationErrorValue 
     header parameter end-to-end (or middle-to-end if the value was 
     inserted by a intermediary), so recipients of either header need to 
     implicitly trust the header contents, and take whatever precautions 
     each entity deems appropriate give these facts.


  9.  IANA Considerations

     The following are the IANA considerations made by this SIP
     extension.  Modifications and additions to these registrations 
     require a standards track RFC (Standards Action).


  9.1 IANA Registration for the SIP Geolocation Header 

     The SIP Geolocation header is created by this document, with its 
     definition and rules in Section 4.1 of this document, to be added to
     the sip-parameters, in the portion titled "Header Field Parameters 
     and Parameter Values".







  Polk & Rosen              Expires Sept 9, 2009                [Page 38]
  Internet Draft         Location Conveyance in SIP              Mar 2009

                                              Predefined
     Header Field        Parameter Name       Values      Reference
     ----------------    -------------------  ----------  --------- 
     Geolocation         inserted-by=         no          [this doc]
     Geolocation         used-for-routing     no          [this doc]


  9.2 IANA Registration for New SIP Option Tag 

     The SIP option tag "geolocation" is created by this document, with 
     the definition and rule in Section 4.4 of this document, to be added 
     to sip-parameters within IANA.


  9.3 IANA Registration for Response Code 424

     Reference: RFC-XXXX (i.e., this document)
     Response code: 424 (recommended number to assign)
     Default reason phrase: Bad Location Information

     This SIP Response code is defined in section 4.2 of this document.


  9.4 IANA Registration of New Geolocation-Error Header

     The SIP Geolocation-error header is created by this document, with 
     its definition and rules in Section 4.3 of this document, to be 
     added to the sip-parameters, in the portion titled "Header Field 
     Parameters and Parameter Values".

                                              Predefined
     Header Field        Parameter Name       Values      Reference
     -----------------   -------------------  ----------  --------- 
     Geolocation-Error   inserter=            no          [this doc]
     Geolocation-Error   node=                no          [this doc]
     Geolocation-Error   code=                no          [this doc]


  9.5 IANA Registration for the SIP Geolocation-Error Codes 

     New location specific Geolocation-Error codes are created by this 
     document, and registered in a new table at sip-parameters within 
     IANA. Details of these error codes are in Section 4.3 of this 
     document.

     Geolocation-Error codes
     ----------------------- 
     Geolocation-Error codes provide reason for the error discovered by 
     Location Recipients, categorized by action to be taken by error 
     recipient to be placed into SIP responses to inform the location 
     inserter of the error.



  Polk & Rosen              Expires Sept 9, 2009                [Page 39]
  Internet Draft         Location Conveyance in SIP              Mar 2009

    Code Description                                          Reference
    ---- ---------------------------------------------------  ---------
    100  "Cannot Process Location"  General location error,   [this doc]
            meaning location in the request cannot be 
            processed at this time.  No actionable guidance.  
            Can be treated as a 200 or 300 error by error 
            recipient.

    200  "Retry Location Later" (with same data)  Location    [this doc]
            cannot be processed at this time.  Error recipient 
            should try again with same data.

    300  "Retry Location Later" (with device updated location) [this doc]
            Location cannot be processed at this time.  Error 
            recipient should try again with same data.

    400  "Permission Necessary"  Permission from calling user [this doc]
            to reveal location in request before request can 
            be processed.  This is a routing by location error.
            User MUST be informed of permission request.

    500  "Location Information Denial"  Request was actively 
            denied because of the location in the request.  
            Recipient should not try again.


  9.6  IANA Registration of LbyR Schemes

     This document directs IANA to create a new set of parameters in a 
     separate location from SIP and Geopriv, called the "Location 
     Reference URI" registry, containing the URI scheme, the 
     Content-Type, and the reference.  Below is an example of how it 
     could look


     URI Scheme   Content-Type           Reference
     ----------   ------------           ---------
        SIP:                             [this doc]
        SIPS:                            [this doc]
        PRES:                            [this doc]

     Additions to this registry require an industry specification.


  10.  Acknowledgements

     To Dave Oran for helping to shape this idea. To Jon Peterson and 
     Dean Willis on guidance of the effort. To Allison Mankin, Dick 
     Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, 
     Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith 
     Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat, 
     Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie, Matt 


  Polk & Rosen              Expires Sept 9, 2009                [Page 40]
  Internet Draft         Location Conveyance in SIP              Mar 2009

     Lepinski and Jacqueline Lee for constructive feedback and nits 
     checking.  

     A special thanks to Paul Kyzivat for his help with the ABNF in this 
     document, to Dan Wing for help with the S/MIME example, and to 
     Robert Sparks for many helpful comments and the proper building of 
     the Geolocation-Error header.


  11. References 

  11.1 References - Normative

   [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
             Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
             Session Initiation Protocol", RFC 3261, May 2002.

   [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 
             Format", RFC 4119, December 2005

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

   [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 
             Locators", RFC 2392, August 1998 

   [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. 
             Peterson, "Presence Information Data Format (PIDF)", RFC 
             3863, August 2004

   [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 
             Initiation Protocol (SIP)", RFC 3856, August 2004

   [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 
             August 2004

   [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
             D. Gurle, "Session Initiation Protocol (SIP) Extension for
             Instant Messaging" , RFC 3428, December 2002

   [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
             Method", RFC 3311, October 2002

   [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
             Event Notification", RFC 3265, June 2002.

   [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
             Provisional Responses in Session Initiation Protocol (SIP)",
             RFC 3262, June 2002.

   [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000



  Polk & Rosen              Expires Sept 9, 2009                [Page 41]
  Internet Draft         Location Conveyance in SIP              Mar 2009

   [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer
             Method", RFC 3515, April 2003

   [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension
             for Event State Publication", RFC 3903, October 2004. 

   [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 
             Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [IANA-civic] http://www.iana.org/assignments/civic-address-types-
                       registry


  11.2 References - Informative

   [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 
             "Geopriv Requirements", RFC 3693, February 2004

   [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
             Configuration Protocol Option for Coordinate-based Location
             Configuration Information", RFC 3825, July 2004

   [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 
             (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
             Information ", RFC 4776, October 2006


     Author Information

     James Polk                                     
     Cisco Systems                                     
     3913 Treemont Circle                              
     Colleyville, Texas  76034                         

     33.00111N
     96.68142W

     Phone: +1-817-271-3552
     Email: jmpolk@cisco.com


     Brian Rosen
     NeuStar, Inc.
     470 Conrad Dr.                                    
     Mars, PA  16046                                   
     
     40.70497N
     80.01252W

     Phone: +1 724 382 1051
     Email: br@brianrosen.net



  Polk & Rosen              Expires Sept 9, 2009                [Page 42]
  Internet Draft         Location Conveyance in SIP              Mar 2009


  Appendix A.  Requirements for SIP Location Conveyance

     The following subsections address the requirements placed on the 
     UAC, the UAS, as well as SIP proxies when conveying location. There 
     is a motivational statement below each requirements that is not 
     obvious in intent

  A.1 Requirements for a UAC Conveying Location

     UAC-1  The SIP INVITE Method [RFC3261] must support location 
            conveyance.

     UAC-2  The SIP MESSAGE method [RFC3428] must support location 
            conveyance.

     UAC-3  SIP Requests within a dialog should support location 
            conveyance.

     UAC-4  Other SIP Requests may support location conveyance.

     UAC-5  There must be one, mandatory to implement means of 
            transmitting location confidentially.

     Motivation:  interoperability 

     UAC-6  It must be possible for a UAC to update location conveyed 
            at any time in a dialog, including during dialog 
            establishment.

     Motivation: in case a UAC has moved prior to the establishment of a 
            dialog between UAs, the UAC must be able to send new location
            information.  In the case of location having been conveyed, 
            and the UA moves, it needs a means to update the conveyed to 
            party of this location change.

     UAC-7  The privacy and security rules established within [RFC3693] 
            that would categorize SIP as a 'Using Protocol' must be met.

     UAC-8  The PIDF-LO [RFC4119] is a mandatory to implement format for
            location conveyance within SIP, whether included LbyV or 
            LbyR.

     Motivation:  interoperability with other IETF location protocols and 
            mechanisms

     UAC-9  There must be a mechanism for the UAC to request the UAS send 
            its location

            UAC-9 has been DEPRECATED by the SIP WG, due to the many 
            problems this requirement would have caused if implemented. 
            The solution is for the above UAS to send a new request to 


  Polk & Rosen              Expires Sept 9, 2009                [Page 43]
  Internet Draft         Location Conveyance in SIP              Mar 2009

            the original UAC with the UAS's location.

     UAC-10 There must be a mechanism to differentiate the ability of the 
            UAC to convey location from the UACs lack of knowledge of its 
            location 

     Motivation: Failure to receive location when it is expected can be 
            because the UAC does not implement this extension, or it can 
            be that the UAC implements the extension, but does not know 
            where it is.  This may be, for example, due to the failure of 
            the access network to provide a location acquisition 
            mechanisms the UAC understands.  These cases must be 
            differentiated.


     UAC-11  It must be possible to convey location to proxy servers 
            along the path.

     Motivation:  Location-based routing.


  A.2 Requirements for a UAS Receiving Location

     The following are the requirements for location conveyance by a UAS:

     UAS-1  SIP Responses must support location conveyance.

            Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, 
            due to the many problems this requirement would have caused 
            if implemented. The solution is for the above UAS to send a 
            new request to the original UAC with the UAS's location.

     UAS-2  There must be a unique 4XX response informing the UAC it did
            not provide applicable location information.

     In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS


  A.3 Requirements for SIP Proxies and Intermediaries 

     The following are the requirements for location conveyance by a SIP 
     proxies and intermediaries:

     Proxy-1  Proxy servers must be capable of adding a Location header 
              field during processing of SIP requests.

     Motivation:  Provide the capability of network assertion of location
              when UACs are unable to do so, or when network assertion is
              more reliable than UAC assertion of location

     Note: Because UACs connected to sip signaling networks may have 
           widely varying access network arrangements, including VPN 


  Polk & Rosen              Expires Sept 9, 2009                [Page 44]
  Internet Draft         Location Conveyance in SIP              Mar 2009

           tunnels and roaming mechanisms, it may be difficult for a 
           network to reliably know the location of the endpoint.  Proxy 
           assertion of location is NOT RECOMMENDED unless the sip 
           signaling network has reliable knowledge of the actual 
           location of the Targets.

     Proxy-2  There must be a unique 4XX response informing the UAC it 
              did not provide applicable location information.

  Appendix B. Example of INVITE with S/MIME encrypted Civic PIDF-LO 

     This appendix gives an *EXAMPLE* (meaning this might contain errors 
     based on future review) of a SIP INVITE request that points to the 
     same position on the earth as the coordinate based example that is 
     in section 5.1 in the body of this document:

     The INVITE request is TLS hop-by-hop encrypted, and the 
     LbyV message body is S/MIME encrypted. This example 
     shows the location message body in its unencrypted form for clarity.
     The message body lines below that have the '$' signs are S/MIME 
     encrypted.  In this example, the SDP is not S/MIME encrypted.  A 
     complete list of IANA registered CAtypes can be found at 
     [IANA-civic].

     INVITE sips:bob@biloxi.example.com SIP/2.0
     Via: SIP/2.0/TLS pc33.atlanta.example.com
       ;branch=z9hG4bK74bf9
     Max-Forwards: 70
     To: Bob <sips:bob@biloxi.example.com>
     From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl 
     Call-ID: 3848276298220188511@atlanta.example.com
     Geolocation: <cid:target123@atlanta.example.com> 
       ;inserted-by="alice@atlanta.example.com" 
     Supported: geolocation 
     Accept: application/sdp, application/pidf+xml
     CSeq: 31862 INVITE
     Contact: <sips:alice@pc33.atlanta.example.com>
     Content-Type: multipart/mixed; boundary=boundary1
     Content-Length: ...

     --boundary1

     Content-Type: application/sdp

     ...SDP goes here

     --boundary1

     Content-Type: application/pkcs7-mime; 
        smime-type=enveloped-data; name=smime.p7m
     Content-ID: <target123@atlanta.example.com>



  Polk & Rosen              Expires Sept 9, 2009                [Page 45]
  Internet Draft         Location Conveyance in SIP              Mar 2009

  $  Content-Type: application/pidf+xml
  $ 
  $  <?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:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
  $         entity="pres:alice@atlanta.example.com">
  $       <tuple id="sg89ae">
  $        <timestamp>2007-07-09T14:00:00Z</timestamp>
  $        <status>
  $         <gp:geopriv>
  $           <gp:location-info>
  $             <cl:civicAddress>
  $               <cl:country>US</cl:country>
  $               <cl:A1>Texas</cl:A1>
  $               <cl:A3>Colleyville</cl:A3>
  $               <cl:HNO>3913</cl:HNO>
  $               <cl:A6>Treemont</cl:A6>
  $               <cl:STS>Circle</cl:STS>
  $               <cl:PC>76034</cl:PC>
  $               <cl:NAM>Haley's Place</cl:NAM>
  $               <cl:FLR>1</cl:FLR>
  $             <cl:civicAddress>
  $           </gp:location-info>
  $           <gp:usage-rules>
  $             <gp:retransmission-allowed>no</gp:retransmission-allowed>
  $             <gp:retention-expiry>2007-07-27T18:00:00Z</gp:retention-
  $                           expiry>
  $           </gp:usage-rules>
  $           <gp:method>DHCP</gp:method>
  $           <gp:provided-by>www.example.com</gp:provided-by>
  $         </gp:geopriv>
  $        </status>
  $       </tuple>
  $      </presence>
     --boundary1--


















  Polk & Rosen              Expires Sept 9, 2009                [Page 46] 


name: draft-ietf-websec-mime-sniff
rev: 03
title: Media Type Sniffing
time: 2024-09-24T23:12:02Z
group_uri: /api/v1/group/group/1802/
expires: 2011-11-08T08:00:03Z
ad: /api/v1/person/person/105907/
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.733583+00:00
source: ietf
source_id: 36839
source_url: https://datatracker.ietf.org/doc/draft-ietf-websec-mime-sniff/
doc_status: active
abstract:
  Many web servers supply incorrect Content-Type header fields with
  their HTTP responses.  In order to be compatible with these servers,
  user agents consider the content of HTTP responses as well as the
  Content-Type header fields when determining the effective media type
  of the response.  This document describes an algorithm for
  determining the effective media type of HTTP responses that balances
  security and compatibility considerations.

  Please send feedback on this draft to websec@ietf.org.

full_text:
  None                                                            A. Barth
  Internet-Draft                                                I. Hickson
  Expires: November 8, 2011                                   Google, Inc.
                                                               May 7, 2011


                            Media Type Sniffing
                      draft-ietf-websec-mime-sniff-03

  Abstract

     Many web servers supply incorrect Content-Type header fields with
     their HTTP responses.  In order to be compatible with these servers,
     user agents consider the content of HTTP responses as well as the
     Content-Type header fields when determining the effective media type
     of the response.  This document describes an algorithm for
     determining the effective media type of HTTP responses that balances
     security and compatibility considerations.

     Please send feedback on this draft to websec@ietf.org.

  Status of this Memo

     This Internet-Draft is submitted to IETF in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt.

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     This Internet-Draft will expire on November 8, 2011.

  Copyright Notice

     Copyright (c) 2011 IETF Trust and the persons identified as the
     document authors.  All rights reserved.



  Barth & Hickson         Expires November 8, 2011                [Page 1]


  Internet-Draft             Media Type Sniffing                  May 2011


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (http://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with respect
     to this document.  Code Components extracted from this document must
     include Simplified BSD License text as described in Section 4.e of
     the Trust Legal Provisions and are provided without warranty as
     described in the BSD License.


  Table of Contents

     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.  Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.  Web Pages  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.  Text or Binary . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.  Unknown Type . . . . . . . . . . . . . . . . . . . . . . . . . 11
       6.1.  Signature for MP4  . . . . . . . . . . . . . . . . . . . . 16
     7.  Image  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.  Video  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.  Fonts  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     10. Feed or HTML . . . . . . . . . . . . . . . . . . . . . . . . . 20
     11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
       11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
       11.2. Informative References . . . . . . . . . . . . . . . . . . 23
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24























  Barth & Hickson         Expires November 8, 2011                [Page 2]


  Internet-Draft             Media Type Sniffing                  May 2011


  1.  Introduction

     The HTTP Content-Type header field indicates the media type of an
     HTTP response.  However, many HTTP servers supply a Content-Type that
     does not match the actual contents of the response.  Historically,
     web browsers have tolerated these servers by examining the content of
     HTTP responses in addition to the Content-Type header field to
     determine the effective media type of the response.

     Without a clear specification of how to "sniff" the media type, each
     user agent implementor was forced to reverse engineer the behavior of
     the other user agents and to develop their own algorithm.  These
     divergent algorithms have lead to a lack of interoperability between
     user agents and to security issues when the server intends an HTTP
     response to be interpreted as one media type but some user agents
     interpret the responses as another media type.

     These security issues are most severe when an "honest" server lets
     potentially malicious users upload files and then serves the contents
     of those files with a low-privilege media type (such as text/plain or
     image/jpeg).  (Malicious servers, of course, can specify an arbitrary
     media type in the Content-Type header field.)  In the absence of
     media type sniffing, this user-generated content would not be
     interpreted as a high-privilege media type, such as text/html.
     However, if a user agent does interpret a low-privilege media type,
     such as image/gif, as a high-privilege media type, such as text/html,
     the user agent has created a privilege escalation vulnerability in
     the server.  For example, a malicious user might be able to leverage
     content sniffing to mount a cross-site script attack by including
     JavaScript code in the uploaded file that a user agent treats as
     text/html.

     This document describes a content sniffing algorithm that carefully
     balances the compatibility needs of user agent implementors with the
     security constraints.  The algorithm has been constructed with
     reference to content sniffing algorithms present in popular user
     agents, an extensive database of existing web content, and metrics
     collected from implementations deployed to a sizable number of users
     [BarthCaballeroSong2009].

     WARNING!  Whenever possible, user agents SHOULD NOT employ a content
     sniffing algorithm.  However, if a user agent does employ a content
     sniffing algorithm, the user agent SHOULD use the algorithm in this
     document because using a different content sniffing algorithm than
     servers expect causes security problems.  For example, if a server
     believes that the client will treat a contributed file as an image
     (and thus treat it as benign), but a user agent believes the content
     to be HTML (and thus privileged to execute any scripts contained



  Barth & Hickson         Expires November 8, 2011                [Page 3]


  Internet-Draft             Media Type Sniffing                  May 2011


     therein), an attacker might be able to steal the user's
     authentication credentials and mount other cross-site scripting
     attacks.

     Conformance requirements phrased as algorithms or specific steps MAY
     be implemented in any manner, so long as the end result is
     equivalent.  (In particular, the algorithms defined in this
     specification are intended to be easy to follow, and not intended to
     be performant.)










































  Barth & Hickson         Expires November 8, 2011                [Page 4]


  Internet-Draft             Media Type Sniffing                  May 2011


  2.  Conventions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].

     Requirements phrased in the imperative as part of algorithms (such as
     "strip any leading space characters" or "return false and abort these
     steps") are to be interpreted with the meaning of the key word
     ("MUST", "SHOULD", "MAY", etc) used in introducing the algorithm.

     Conformance requirements phrased as algorithms or specific steps can
     be implemented in any manner, so long as the end result is
     equivalent.  In particular, the algorithms defined in this
     specification are intended to be easy to understand and are not
     intended to be performant.



































  Barth & Hickson         Expires November 8, 2011                [Page 5]


  Internet-Draft             Media Type Sniffing                  May 2011


  3.  Metadata

     The explicit media type metadata information associated with sequence
     of octets depends on the protocol that was used to fetch the octets.

     For octets received via HTTP, the Content-Type HTTP header field, if
     present, indicates the media type.  Let the official-type be the
     media type indicted by the HTTP Content-Type header field, if
     present.  If the Content-Type header field is absent or if its value
     cannot be interpreted as a media type (e.g. because its value doesn't
     contain a U+002F SOLIDUS ('/') character), then there is no official-
     type.  (Such messages are invalid according to [RFC2616]

        Note: If an HTTP response contains multiple Content-Type header
        fields, the user agent MUST use the textually last Content-Type
        header field to the official-type.  For example, if the last
        Content-Type header field contains the value "foo", then there is
        no official media type because "foo" cannot be interpreted as a
        media type (even if the HTTP response contains another Content-
        Type header field that could be interpreted as a media type).

     For octets fetched from the file system, user agents should use
     platform-specific conventions (e.g., operating system file extension/
     type mappings) to determine the official-type.

        Note: It is essential that file extensions are not used for
        determining the media type for octets fetched over HTTP because,
        in some cases, file extensions can be supplied by malicious
        parties.  For example, most PHP installations let the attacker
        append arbitrary path information to URLs (e.g.,
        http://example.com/foo.php/bar.html) and thereby determine the
        file extension.

     For octets fetched over some other protocols, e.g.  FTP [RFC0959],
     there is no type information.

     Note: Comparisons between media types, as defined by MIME
     specifications, are done in an ASCII case-insensitive manner.
     [RFC2046]












  Barth & Hickson         Expires November 8, 2011                [Page 6]


  Internet-Draft             Media Type Sniffing                  May 2011


  4.  Web Pages

     The user agent MUST use the following algorithm to determine the
     sniffed-type of a sequence of octets:

     1.  If the user agent is configured to strictly obey the official-
         type, then let the sniffed-type be the official-type and abort
         these steps.

     2.  If the octets were fetched via HTTP and there is an HTTP Content-
         Type header field and the value of the last such header field has
         octets that *exactly* match the octets contained in one of the
         following lines:

        +-------------------------------+--------------------------------+
        | Bytes in Hexadecimal          | Textual Representation         |
        +-------------------------------+--------------------------------+
        | 74 65 78 74 2f 70 6c 61 69 6e | text/plain                     |
        +-------------------------------+--------------------------------+
        | 74 65 78 74 2f 70 6c 61 69 6e | text/plain; charset=ISO-8859-1 |
        | 3b 20 63 68 61 72 73 65 74 3d |                                |
        | 49 53 4f 2d 38 38 35 39 2d 31 |                                |
        +-------------------------------+--------------------------------+
        | 74 65 78 74 2f 70 6c 61 69 6e | text/plain; charset=iso-8859-1 |
        | 3b 20 63 68 61 72 73 65 74 3d |                                |
        | 69 73 6f 2d 38 38 35 39 2d 31 |                                |
        +-------------------------------+--------------------------------+
        | 74 65 78 74 2f 70 6c 61 69 6e | text/plain; charset=UTF-8      |
        | 3b 20 63 68 61 72 73 65 74 3d |                                |
        | 55 54 46 2d 38                |                                |
        +-------------------------------+--------------------------------+

         ...then jump to the "text or binary" section below.

     3.  If there is no official-type, jump to the "unknown type" section
         below.

     4.  If the official-type is "unknown/unknown", "application/unknown",
         or "*/*", jump to the "unknown type" section below.

     5.  If the official-type ends in "+xml", or if it is either "text/
         xml" or "application/xml", then let the sniffed-type be the
         official-type and abort these steps.

     6.  If the official-type is an image type supported by the user agent
         (e.g., "image/png", "image/gif", "image/jpeg", etc), then jump to
         the "images" section below.




  Barth & Hickson         Expires November 8, 2011                [Page 7]


  Internet-Draft             Media Type Sniffing                  May 2011


     7.  If the official-type is "text/html", then jump to the "feed or
         HTML" section below.

     8.  Let the sniffed-type be the official type.















































  Barth & Hickson         Expires November 8, 2011                [Page 8]


  Internet-Draft             Media Type Sniffing                  May 2011


  5.  Text or Binary

     This section defines the *rules for distinguishing if a resource is
     text or binary*.

     1.  The user agent MAY wait for 512 or more octets to arrive.

            Note: Waiting for 512 octets octets to arrive causes the text-
            or-binary algorithm to be deterministic for a given sequence
            of octets.  However, in some cases, the user agent might need
            to wait an arbitrary length of time for these octets to
            arrive.  User agents SHOULD wait for 512 octets to arrive,
            when feasible.

     2.  Let n be the smaller of either 512 or the number of octets that
         have already arrived.

     3.  If n is greater than or equal to 3, and the first 2 or 3 octets
         match one of the following octet sequences:

                     +----------------------+--------------+
                     | Bytes in Hexadecimal | Description  |
                     +----------------------+--------------+
                     | FE FF                | UTF-16BE BOM |
                     | FF FE                | UTF-16LE BOM |
                     | EF BB BF             | UTF-8 BOM    |
                     +----------------------+--------------+

         ...then let the sniffed-type be "text/plain" and abort these
         steps.

     4.  If none of the first n octets are binary data octets then let the
         sniffed-type be "text/plain" and abort these steps.

                           +-------------------------+
                           | Binary Data Byte Ranges |
                           +-------------------------+
                           | 0x00 -- 0x08            |
                           | 0x0B                    |
                           | 0x0E -- 0x1A            |
                           | 0x1C -- 0x1F            |
                           +-------------------------+

     5.  If the first octets match one of the octet sequences in the
         "pattern" column of the table in the "unknown type" section
         below, ignoring any rows whose cell in the "security" column says
         "scriptable" (or "n/a"), then let the sniffed-type be the type
         given in the corresponding cell in the "sniffed type" column on



  Barth & Hickson         Expires November 8, 2011                [Page 9]


  Internet-Draft             Media Type Sniffing                  May 2011


         that row and abort these steps.

            WARNING!  It is critical that this step not ever return a
            scriptable type (e.g., text/html), because otherwise that
            would allow a privilege escalation attack.

     6.  Otherwise, let the sniffed-type be "application/octet-stream" and
         abort these steps.











































  Barth & Hickson         Expires November 8, 2011               [Page 10]


  Internet-Draft             Media Type Sniffing                  May 2011


  6.  Unknown Type

     1.  The user agent MAY wait for 512 or more octets to arrive for the
         same reason as in the "text or binary" section above.

     2.  Let n be the smaller of either 512 or the number of octets that
         have already arrived.

     3.  For each row in the table below:

         *  If the row has no "WS" octets:

            1.  Let pattern-length be the length of the pattern.

            2.  If n is smaller than pattern-length then skip this row.

            3.  Apply the bit-wise "and" operator to the first pattern-
                length octets and the given mask, and let the result be
                the masked-data.

            4.  If the octets of the masked-data matches the given pattern
                octets exactly, then let the sniffed-type be the type
                given in the cell of the third column in that row and
                abort these steps.

         *  If the row has a "WS" octet or a "_>" octet:

            1.  Let index-pattern be an index into the mask and pattern
                octet strings of the row.

            2.  Let index-stream be an index into the octet stream being
                examined.

            3.  LOOP: If index-stream points beyond the end of the octet
                stream, then this row doesn't match and skip this row.

            4.  Examine the index-stream-th octet of the octet stream as
                follows:

                -  If the index-pattern-th octet of the pattern is a
                   normal hexadecimal octet and not a "WS" octet or a "_>"
                   octet:

                      If the bit-wise "and" operator, applied to the
                      index-stream-th octet of the stream and the index-
                      pattern-th octet of the mask, yield a value
                      different than the index-pattern-th octet of the
                      pattern, then skip this row.



  Barth & Hickson         Expires November 8, 2011               [Page 11]


  Internet-Draft             Media Type Sniffing                  May 2011


                      Otherwise, increment index-pattern to the next octet
                      in the mask and pattern and index-stream to the next
                      octet in the octet stream.

                -  Otherwise, if the index-pattern-th octet of the pattern
                   is a "WS" octet:

                      "WS" means "whitespace", and allows insignificant
                      whitespace to be skipped when sniffing for a type
                      signature.

                      If the index-stream-th octet of the stream is one of
                      0x09 (ASCII TAB), 0x0A (ASCII LF), 0x0C (ASCII FF),
                      0x0D (ASCII CR), or 0x20 (ASCII space), then
                      increment only the index-stream to the next octet in
                      the octet stream.

                      Otherwise, increment only the index-pattern to the
                      next octet in the mask and pattern.

                -  Otherwise, if the index-pattern-th octet of the pattern
                   is a "_>" octet:

                      "_>" means "space-or-bracket", and allows HTML tag
                      names to terminate with either a space or a greater
                      than sign.

                      If index-stream-th octet of the stream is different
                      than 0x20 (ASCII space) or 0x3E (ASCII ">"), then
                      skip this row.

                      Otherwise, increment index-pattern to the next octet
                      in the mask and pattern and index-stream to the next
                      octet in the octet stream.

            5.  If index-pattern does not point beyond the end of the mask
                and pattern octet strings, then jump back to the LOOP step
                in this algorithm.

            6.  Otherwise, let the sniffed-type be the type given in the
                cell of the third column in that row and abort these
                steps.

     4.  If the first n octets match the signature for MP4 (as define in
         Section 6.1), then let the sniffed-type be video/mp4 and abort
         these steps.





  Barth & Hickson         Expires November 8, 2011               [Page 12]


  Internet-Draft             Media Type Sniffing                  May 2011


     5.  If none of the first n octets are binary data (as defined in the
         "text or binary" section), then let the sniffed-type be "text/
         plain" and abort these steps.

     6.  Otherwise, let the sniffed-type be "application/octet-stream" and
         abort these steps.

     The table used by the above algorithm is:

  +-------------------+-------------------+-----------------+------------+
  | Mask in Hex       | Pattern in Hex    | Sniffed Type    | Security   |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF DF DF DF | WS 3C 21 44 4F 43 | text/html       | Scriptable |
  | DF DF DF DF FF DF | 54 59 50 45 20 48 |                 |            |
  | DF DF DF FF       | 54 4D 4C _>       |                 |            |
  | Comment: <!DOCTYPE HTML                                              |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF DF | WS 3C 48 54 4D 4C | text/html       | Scriptable |
  | FF                | _>                |                 |            |
  | Comment: <HTML                                                       |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF DF | WS 3C 48 45 41 44 | text/html       | Scriptable |
  | FF                | _>                |                 |            |
  | Comment: <HEAD                                                       |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF DF | WS 3C 53 43 52 49 | text/html       | Scriptable |
  | DF DF FF          | 50 54 _>          |                 |            |
  | Comment: <SCRIPT                                                     |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF DF | WS 3C 49 46 52 41 | text/html       | Scriptable |
  | DF DF FF          | 4d 45 _>          |                 |            |
  | Comment: <IFRAME                                                     |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF FF FF    | WS 3C 48 31 _>    | text/html       | Scriptable |
  | Comment: <H1                                                         |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF FF | WS 3C 44 49 56 _> | text/html       | Scriptable |
  | Comment: <DIV                                                        |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF DF | WS 3C 46 4f 4e 54 | text/html       | Scriptable |
  | FF                | _>                |                 |            |
  | Comment: <FONT                                                       |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF DF | WS 3C 54 41 42 4c | text/html       | Scriptable |
  | DF FF             | 45 _>             |                 |            |
  | Comment: <TABLE                                                      |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF FF       | WS 3C 41 _>       | text/html       | Scriptable |



  Barth & Hickson         Expires November 8, 2011               [Page 13]


  Internet-Draft             Media Type Sniffing                  May 2011


  | Comment: <A                                                          |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF DF | WS 3C 53 54 59 4c | text/html       | Scriptable |
  | DF FF             | 45 _>             |                 |            |
  | Comment: <STYLE                                                      |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF DF | WS 3C 54 49 54 4c | text/html       | Scriptable |
  | DF FF             | 45 _>             |                 |            |
  | Comment: <TITLE                                                      |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF FF       | WS 3C 42 _>       | text/html       | Scriptable |
  | Comment: <B                                                          |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF DF DF | WS 3C 42 4f 44 59 | text/html       | Scriptable |
  | FF                | _>                |                 |            |
  | Comment: <BODY                                                       |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF DF FF    | WS 3C 42 52 _>    | text/html       | Scriptable |
  | Comment: <BR                                                         |
  +-------------------+-------------------+-----------------+------------+
  | FF FF DF FF       | WS 3C 50 _>       | text/html       | Scriptable |
  | Comment: <P                                                          |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF FF FF | WS 3C 21 2d 2d _> | text/html       | Scriptable |
  | Comment: <!--                                                        |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF FF FF | WS 3C 3f 78 6d 6c | text/xml        | Scriptable |
  | Comment: <?xml (Note the case sensitivity and lack of trailing _>)  |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF FF    | 25 50 44 46 2D    | application/pdf | Scriptable |
  | Comment: The string "%PDF-", the PDF signature.                      |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF FF FF | 25 21 50 53 2D 41 | application/    | Safe       |
  | FF FF FF FF FF    | 64 6F 62 65 2D    |      postscript |            |
  | Comment: The string "%!PS-Adobe-", the PostScript signature.         |
  +-------------------+-------------------+-----------------+------------+
  | FF FF 00 00       | FE FF 00 00       | text/plain      | n/a        |
  | Comment: UTF-16BE BOM                                                |
  +-------------------+-------------------+-----------------+------------+
  | FF FF 00 00       | FF FE 00 00       | text/plain      | n/a        |
  | Comment: UTF-16LE BOM                                                |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF 00       | EF BB BF 00       | text/plain      | n/a        |
  | Comment: UTF-8 BOM                                                   |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF FF FF | 47 49 46 38 37 61 | image/gif       | Safe       |
  | Comment: The string "GIF87a", a GIF signature.                       |
  +-------------------+-------------------+-----------------+------------+



  Barth & Hickson         Expires November 8, 2011               [Page 14]


  Internet-Draft             Media Type Sniffing                  May 2011


  | FF FF FF FF FF FF | 47 49 46 38 39 61 | image/gif       | Safe       |
  | Comment: The string "GIF89a", a GIF signature.                       |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF FF FF | 89 50 4E 47 0D 0A | image/png       | Safe       |
  | FF FF             | 1A 0A             |                 |            |
  | Comment: The PNG signature.                                          |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF          | FF D8 FF          | image/jpeg      | Safe       |
  | Comment: A JPEG SOI marker followed by a octet of another marker.    |
  +-------------------+-------------------+-----------------+------------+
  | FF FF             | 42 4D             | image/bmp       | Safe       |
  | Comment: The string "BM", a BMP signature.                           |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF 00 00 | 52 49 46 46 00 00 | image/webp      | Safe       |
  | 00 00 FF FF FF FF | 00 00 57 45 42 50 |                 |            |
  | FF FF             | 56 50             |                 |            |
  | Comment: "RIFF" followed by four bytes, followed by "WEBPVP".        |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF       | 00 00 01 00       | image/vnd.      | Safe       |
  |                   |                   |  microsoft.icon |            |
  | Comment: A Windows Icon signature.                                   |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF FF    | 4F 67 67 53 00    | application/ogg | Safe       |
  | Comment: An Ogg audio or video signature.                     |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF 00 00 | 52 49 46 46 00 00 | audio/wave      | Safe       |
  | 00 00 FF FF FF FF | 00 00 57 41 56 45 |                 |            |
  | Comment: "RIFF" followed by four bytes, followed by "WAVE".          |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF       | 1A 45 DF A3       | video/webm      | Safe       |
  | Comment: The WebM signature [TODO: Use more octets?]                 |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF FF FF | 52 61 72 20 1A 07 | application/    | Safe       |
  | FF                | 00                | x-rar-compressed|            |
  | Comment: A RAR archive.                                              |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF FF       | 50 4B 03 04       | application/zip | Safe       |
  | Comment: A ZIP archive.                                              |
  +-------------------+-------------------+-----------------+------------+
  | FF FF FF          | 1F 8B 08          | application/    | Safe       |
  |                   |                   |          x-gzip |            |
  | Comment: A GZIP archive.                                             |
  +-------------------+-------------------+-----------------+------------+
  [TODO: MP3 audio.]

     User agents MAY support additional types if necessary, by implicitly
     adding to the above table.  However, user agents SHOULD NOT not use
     any other patterns for types already mentioned in the table above



  Barth & Hickson         Expires November 8, 2011               [Page 15]


  Internet-Draft             Media Type Sniffing                  May 2011


     because this could then be used for privilege escalation (where,
     e.g., a server uses the above table to determine that content is not
     HTML and thus safe from cross-site scripting attacks, but then a user
     agent detects it as HTML anyway and allows script to execute).  In
     extending this table, user agents SHOULD NOT introduce any privilege
     escalation vulnerabilities.

     Note: The column marked "security" is used by the algorithm in the
     "text or binary" section, to avoid sniffing text/plain content as a
     type that can be used for a privilege escalation attack.

  6.1.  Signature for MP4

     This section defines whether a sequence of n octets *matches the
     signature for MP4*.

     If n is less than 4, then the sequence does not match the signature
     for MP4 and abort these steps.

     Let box-size be the value of the first four octets, interpreted as a
     32 bit unsigned, little-endian integer.

     If n is less than box-size or if box-size is not evenly divisible by
     4, then the sequence does not match the signature for MP4 and abort
     these steps.

     If octets 5 through 8 (inclusive) of the sequence are not 0x66 0x74
     0x79 0x70 (the ASCII string "ftyp"), then the sequence does not match
     the signature for MP4 and abort these steps.

     For each i from 2 to box-size/4 - 1 (inclusive):

     1.  If i is equal to 3, continue to the next i, if any.  (These
         octets correspond to the minor version number.)

     2.  If octets 4*i through 4*i + 3 (inclusive) of the sequence are
         0x6D 0x70 0x34 (the ASCII string "mp4"), then the sequence *does*
         match the signature for MP4 and abort these steps.

     The sequence does not match the signature for MP4.











  Barth & Hickson         Expires November 8, 2011               [Page 16]


  Internet-Draft             Media Type Sniffing                  May 2011


  7.  Image

     This section defines the *rules for sniffing images specifically*.

     If the official-type is "image/svg+xml", then let the sniffed-type be
     the official-type (an XML type) and abort these steps.

     If the first octets match one of the signatures in Section 6 for one
     of the following media types, then let the sniffed-type be the
     corresponding media type and abort these steps:

     o  image/gif

     o  image/png

     o  image/jpeg

     o  image/bmp

     o  image/vnd.microsoft.icon

     o  image/webp

     Otherwise, let the sniffed-type be the official-type and abort these
     steps.


























  Barth & Hickson         Expires November 8, 2011               [Page 17]


  Internet-Draft             Media Type Sniffing                  May 2011


  8.  Video

     This section defines the *rules for sniffing videos specifically*.

     If the first octets match one of the signatures in Section 6 for one
     of the following media types, then let the sniffed-type be the
     corresponding media type and abort these steps:

     o  video/mp4

     o  video/webm

     o  application/ogg

     Otherwise, let the sniffed-type be the official-type and abort these
     steps.



































  Barth & Hickson         Expires November 8, 2011               [Page 18]


  Internet-Draft             Media Type Sniffing                  May 2011


  9.  Fonts

     This section defines the *rules for sniffing fonts specifically*.

     TODO

     Otherwise, let the sniffed-type be the official-type and abort these
     steps.











































  Barth & Hickson         Expires November 8, 2011               [Page 19]


  Internet-Draft             Media Type Sniffing                  May 2011


  10.  Feed or HTML

     1.   The user agent MAY wait for 512 or more octets to arrive for the
          same reason as in the "text or binary" section above.

     2.   Let s be the stream of octets, and let s[i] represent the octet
          in s with position i, treating s as zero-indexed (so the first
          octet is at i=0).

     3.   If at any point this algorithm requires the user agent to
          determine the value of a octet in s which has not yet arrived,
          or which is past the first 512 octets, or which is beyond the
          end of the octet stream, the algorithm stops and the sniffed-
          type is "text/html".

             Note: User agents are allowed, by the first step of this
             algorithm, to wait until the first 512 octets have arrived.

     4.   Initialize pos to 0.

     5.   If s[0] equals 0xEF, s[1] equals 0xBB, and s[2] equals 0xBF,
          then set pos to 3.  (This skips over a leading UTF-8 BOM, if
          any.)

     6.   LOOP: Examine s[pos].

          *  If it equals 0x09 (ASCII tab), 0x20 (ASCII space), 0x0A
             (ASCII LF), or 0x0D (ASCII CR)

                Increase pos by 1 and repeat this step.

          *  If it equals 0x3C (ASCII "<")

                Increase pos by 1 and go to the next step.

          *  If it is anything else

                Let the sniffed-type be "text/html" and abort these steps.

     7.   If the octets with positions pos to pos+2 in s are exactly equal
          to 0x21, 0x2D, 0x2D respectively (ASCII for "!--"), then:

          1.  Increase pos by 3.

          2.  If the octets with positions pos to pos+2 in s are exactly
              equal to 0x2D, 0x2D, 0x3E respectively (ASCII for "-->"),
              then increase pos by 3 and jump back to the previous step
              (the step labeled loop start) in the overall algorithm in



  Barth & Hickson         Expires November 8, 2011               [Page 20]


  Internet-Draft             Media Type Sniffing                  May 2011


              this section.

          3.  Otherwise, increase pos by 1.

          4.  Return to step 2 in these substeps.

     8.   If s[pos] equals 0x21 (ASCII "!"):

          1.  Increase pos by 1.

          2.  If s[pos] equals 0x3E, then increase pos by 1 and jump back
              to the step labeled LOOP in the overall algorithm in this
              section.

          3.  Otherwise, return to step 1 in these substeps.

     9.   If s[pos] equals 0x3F (ASCII "?"):

          1.  Increase pos by 1.

          2.  If s[pos] and s[pos+1] equal 0x3F and 0x3E respectively,
              then increase pos by 1 and jump back to the step labeled
              LOOP in the overall algorithm in this section.

          3.  Otherwise, return to step 1 in these substeps.

     10.  Otherwise, if the octets in s starting at pos match any of the
          sequences of octets in the first column of the following table,
          then the user agent MUST follow the steps given in the
          corresponding cell in the second column of the same row.

   +----------------------+------------------------------------+---------+
   | Bytes in Hexadecimal | Requirement                        | Comment |
   +----------------------+------------------------------------+---------+
   | 72 73 73             | Let the sniffed-type be            | rss     |
   |                      | "application/rss+xml" and abort    |         |
   |                      | these steps.                       |         |
   +----------------------+------------------------------------+---------+
   | 66 65 65 64          | Let the sniffed-type be            | feed    |
   |                      | "application/atom+xml" and abort   |         |
   |                      | these steps.                       |         |
   +----------------------+------------------------------------+---------+
   | 72 64 66 3A 52 44 46 | Continue to the next step in this  | rdf:RDF |
   |                      | algorithm.                         |         |
   +----------------------+------------------------------------+---------+

          If none of the octet sequences above match the octets in s
          starting at pos, then let the sniffed-type be "text/html" and



  Barth & Hickson         Expires November 8, 2011               [Page 21]


  Internet-Draft             Media Type Sniffing                  May 2011


          abort these steps.

     11.  Initialize RDF-flag to 0.

     12.  Initialize RSS-flag to 0.

     13.  If the octets with positions pos to pos+23 in s are exactly
          equal to 0x68, 0x74, 0x74, 0x70, 0x3A, 0x2F, 0x2F, 0x70, 0x75,
          0x72, 0x6C, 0x2E, 0x6F, 0x72, 0x67, 0x2F, 0x72, 0x73, 0x73,
          0x2F, 0x31, 0x2E, 0x30, 0x2F respectively (ASCII for
          "http://purl.org/rss/1.0/"), then:

          1.  Increase pos by 23.

          2.  Set RSS-flag to 1.

     14.  If the octets with positions pos to pos+42 in s are exactly
          equal to 0x68, 0x74, 0x74, 0x70, 0x3A, 0x2F, 0x2F, 0x77, 0x77,
          0x77, 0x2E, 0x77, 0x33, 0x2E, 0x6F, 0x72, 0x67, 0x2F, 0x31,
          0x39, 0x39, 0x39, 0x2F, 0x30, 0x32, 0x2F, 0x32, 0x32, 0x2D,
          0x72, 0x64, 0x66, 0x2D, 0x73, 0x79, 0x6E, 0x74, 0x61, 0x78,
          0x2D, 0x6E, 0x73, 0x23 respectively (ASCII for
          "http://www.w3.org/1999/02/22-rdf-syntax-ns#"), then:

          1.  Increase pos by 42.

          2.  Set RDF-flag to 1.

     15.  Increase pos by 1.

     16.  If RDF-flag is 1 and RSS-flag is 1, then let the sniffed-type be
          "application/rss+xml" and abort these steps.

     17.  If pos points beyond the end of the octet stream s, then
          continue to step 19 of this algorithm.

     18.  Jump back to step 13 of this algorithm.

     19.  Let the sniffed-type be "text/html" and abort these steps.

     For efficiency reasons, implementations might wish to implement this
     algorithm and the algorithm for detecting the character encoding of
     HTML documents in parallel.








  Barth & Hickson         Expires November 8, 2011               [Page 22]


  Internet-Draft             Media Type Sniffing                  May 2011


  11.  References

  11.1.  Normative References

     [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part Two: Media Types", RFC 2046,
                November 1996.

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

     [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
                Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

  11.2.  Informative References

     [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
                STD 9, RFC 959, October 1985.

     [BarthCaballeroSong2009]
                Barth, A., Caballero, J., and D. Song, "Secure Content
                Sniffing for Web Browsers, or How to Stop Papers from
                Reviewing Themselves", 2009, <http://www.adambarth.com/
                papers/2009/barth-caballero-song.pdf>.


























  Barth & Hickson         Expires November 8, 2011               [Page 23]


  Internet-Draft             Media Type Sniffing                  May 2011


  Authors' Addresses

     Adam Barth
     Google, Inc.

     Email: ietf@adambarth.com
     URI:   http://www.adambarth.com/


     Ian Hickson
     Google, Inc.

     Email: ian@hixie.ch
     URI:   http://ln.hixie.ch/





































  Barth & Hickson         Expires November 8, 2011               [Page 24]



name: draft-ietf-vwrap-authentication
rev: 00
title: VWRAP Trust Model and User Authentication
time: 2024-09-24T23:12:01Z
group_uri: /api/v1/group/group/1769/
expires: 2011-01-06T08:00:00Z
ad: /api/v1/person/person/105907/
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:43.021625+00:00
source: ietf
abstract:
  Authentication in the Virtual World Region Agent Protocol establishes
  an application layer association between a client application and a
  remote service responsible for managing the end user's identity.  The
  objective of authentication is to verify the user of a client
  application possesses appropriate credentials before granting
  capabilities sufficient to assert control over the user's agent and
  digital assets.

full_text:
  Virtual World Region Agent                                        T. Chu
  Protocol                                           Linden Research, Inc.
  Internet-Draft                                                M. Hamrick
  Intended status: Standards Track                            M. Lentczner
  Expires: January 6, 2011                                    July 5, 2010


                 VWRAP Trust Model and User Authentication
                     draft-ietf-vwrap-authentication-00

  Abstract

     Authentication in the Virtual World Region Agent Protocol establishes
     an application layer association between a client application and a
     remote service responsible for managing the end user's identity.  The
     objective of authentication is to verify the user of a client
     application possesses appropriate credentials before granting
     capabilities sufficient to assert control over the user's agent and
     digital assets.

  Status of this Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at http://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on January 6, 2011.

  Copyright Notice

     Copyright (c) 2010 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents
     (http://trustee.ietf.org/license-info) in effect on the date of
     publication of this document.  Please review these documents
     carefully, as they describe your rights and restrictions with respect
     to this document.  Code Components extracted from this document must



  Chu, et al.              Expires January 6, 2011                [Page 1]


  Internet-Draft            VWRAP Authentication                 July 2010


     include Simplified BSD License text as described in Section 4.e of
     the Trust Legal Provisions and are provided without warranty as
     described in the Simplified BSD License.


  Table of Contents

     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
     2.  Agent Login (Resource Class) . . . . . . . . . . . . . . . . .  3
       2.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
         2.1.1.  The Account identifier . . . . . . . . . . . . . . . .  4
         2.1.2.  Flexible Authentication  . . . . . . . . . . . . . . .  4
       2.2.  Service Location . . . . . . . . . . . . . . . . . . . . .  5
       2.3.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . . .  5
         2.3.1.  Account Identifier . . . . . . . . . . . . . . . . . .  5
         2.3.2.  Hashed Password Authenticator  . . . . . . . . . . . .  5
         2.3.3.  Challenge-Response Authenticator . . . . . . . . . . .  5
         2.3.4.  PKCS#5 PBKDF2 Authenticator  . . . . . . . . . . . . .  6
       2.4.  Response . . . . . . . . . . . . . . . . . . . . . . . . .  6
         2.4.1.  Success  . . . . . . . . . . . . . . . . . . . . . . .  6
         2.4.2.  Maintenance Deferred Success . . . . . . . . . . . . .  7
         2.4.3.  Authentication Non-Success . . . . . . . . . . . . . .  7
       2.5.  Errors and Exceptions  . . . . . . . . . . . . . . . . . .  7
         2.5.1.  Authentication Failure . . . . . . . . . . . . . . . .  7
         2.5.2.  User Intervention Required Failure . . . . . . . . . .  7
         2.5.3.  Non Specific Failure . . . . . . . . . . . . . . . . .  7
       2.6.  Preconditions  . . . . . . . . . . . . . . . . . . . . . .  7
         2.6.1.  Client Preconditions . . . . . . . . . . . . . . . . .  7
         2.6.2.  Authentication Service Preconditions . . . . . . . . .  8
       2.7.  Postconditions . . . . . . . . . . . . . . . . . . . . . .  8
         2.7.1.  Client Postconditions  . . . . . . . . . . . . . . . .  8
         2.7.2.  Authentication Service Postconditions  . . . . . . . .  8
       2.8.  Side Effects . . . . . . . . . . . . . . . . . . . . . . .  8
       2.9.  Sequence of Events . . . . . . . . . . . . . . . . . . . .  9
       2.10. Interface  . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.  Login-Time Maintenance (Resource Class)  . . . . . . . . . . . 12
       3.1.  Service Location . . . . . . . . . . . . . . . . . . . . . 13
       3.2.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.3.  Response . . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.4.  Interface  . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
     5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
       6.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
       6.2.  Informative References . . . . . . . . . . . . . . . . . . 15
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15




  Chu, et al.              Expires January 6, 2011                [Page 2]


  Internet-Draft            VWRAP Authentication                 July 2010


  1.  Introduction

     Authentication is the first step in associating a client application
     with virtual world services.  The authentication service may have a
     trust relationship with other services; before a client application
     may interact with them, it must authenticate itself by presenting
     credentials demonstrating its right to control the agent.
     Authentication is the process of presenting a credential to the
     authentication service and receiving a seed capability or an
     actionable error description.

  1.1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in RFC 2119 [RFC2119].


  2.  Agent Login (Resource Class)

  2.1.  Introduction

     Authentication begins by requesting the agent_login resource; that
     is, sending a message to a well-known URL containing a message
     constructed using rules defined using a supported serialization
     scheme for use with the abstract type system
     [I-D.ietf-vwrap-type-system].  The authentication service managing
     this resource then makes an access control decision based on the
     verity of the credential and the state of the service.

     The authentication process results in one of seven classes of
     response from the authentication service:

     o  success

     o  deferred success due to maintenance

     o  authentication non-success due to missing secret

     o  authentication failure

     o  "user intervention required" failure, and

     o  "non-specified" failure.

     Responses to authentication requests are successes, non-successes and
     failures.  A "success" indicates the client application should have
     enough information to progress past the authentication phase and



  Chu, et al.              Expires January 6, 2011                [Page 3]


  Internet-Draft            VWRAP Authentication                 July 2010


     begin using the service.  A "deferred success" implies use of the
     system will continue after a "short" period.  In either case, the
     authentication service does not expect the client application to re-
     submit the agent_login request.  Authentication "non-success" results
     from a client requesting authentication parameters.  After sending a
     "non-success", the authentication service expects the client to
     resubmit the agent_login request "shortly."  Failures of all type
     indicate the authentication service believes a condition exists
     requiring explicit user intervention.  In the case of an
     authentication failure, the user should either retry the
     authentication request or recover their password.  A failure due to
     "user intervention required" indicates the authentication service
     believes the user's account is in a state requiring "out of band"
     recovery.  Reading and accepting the authentication service's Terms
     of Service or Critical Messages are examples of recovering from "user
     intervention required" failures.  Non-Specified failures indicate a
     non-recoverable problem that is not defined in this specification.

     The section below on Processing Expectations provides more guidance.

  2.1.1.  The Account identifier

     Client applications encode user credentials using an "Account
     Identifier."  An "account" is an administrative object holding
     information about the user: shared secret, a reference to an avatar
     shape, a collection of owned virtual items, etc.

     Please note this document does not imply a structure to the account
     identifier.  Though an authentication service may use an email
     address as an account identifier, the protocol does not require it
     and treats the identifier simply as an opaque sequence of octets.

  2.1.2.  Flexible Authentication

     This revision of the Virtual World Region Agent Protocol defines, but
     does not require the use of, three authentication schemes: hashed
     password, challenge-response and PKCS#5 Key Derivation 2.

     Implementers should also note that the authenticator is not required.
     If an authenticator is not present in the agent_login request, the
     authentication service SHOULD make a best-effort attempt to
     authenticate the request from context.  In some cases, the absence of
     the authenticator will imply the authentication has already taken
     place with OAuth or OpenID as described in the "Client Application
     Launch Message" [I-D.ietf-vwrap-launch] document.  In other
     situations, the authentication service SHOULD examine the security
     parameters of the transport.




  Chu, et al.              Expires January 6, 2011                [Page 4]


  Internet-Draft            VWRAP Authentication                 July 2010


  2.2.  Service Location

     Each authentication service MUST have a service URL that is
     communicated to the client application before authentication begins.
     Some services will deploy a fixed, well-known URL while others may
     choose to locate the agent_login resource behind a cryptographically
     unguessable web capability.[I-D.ietf-vwrap-launch]

  2.3.  Inputs

  2.3.1.  Account Identifier

     The account_name key in the credential provided to the authentication
     service is used to identify the account.  This is the opaque sequence
     of octets used by the authentication service to identify the user.

  2.3.2.  Hashed Password Authenticator

     When a hashed password is used as an authenticator, the string '$1$'
     is prepended to the UTF-8 encoding of the password and processed with
     the MD5 cryptographic hash function.  [RFC1321] This revision of the
     Virtual World Region Agent Protocol specification requires the use of
     MD5 with the hashed password authenticator.  It also requires the
     presence of the algorithm key, and that the value of this key be the
     string 'md5'.  Note that future versions of this specification may
     ALLOW or REQUIRE the use of other cryptographic hash functions.

  2.3.3.  Challenge-Response Authenticator

     The Challenge-Response scheme allows the authentication service to
     select a session specific "Salt" to be used in conjunction with the
     user's password to generate an authenticator.  In this scheme the
     authenticator is the hash of the salt prepended to the hash of '$1$'
     prepended to the password.  This revision of the Virtual World Region
     Agent Protocol specification requires the use of SHA256 with the
     challenge-response authenticator. [sha256] It also requires the
     presence of the algorithm key, and that the value of this key be the
     string 'sha256'.  Note that future versions of this specification may
     ALLOW or REQUIRE the use of other cryptographic hash functions.

     To retrieve a session specific salt for use with the Challenge-
     Response authentication scheme from the authentication service, the
     client application sends a login request with a Challenge-Response
     authenticator without the secret item.  If the agent domain supports
     this authenticator, it MUST respond with a 'key' condition including
     a salt and MAY include a duration in the response.  If the duration
     is present, it denotes the number of seconds for which the salt will
     be valid.



  Chu, et al.              Expires January 6, 2011                [Page 5]


  Internet-Draft            VWRAP Authentication                 July 2010


  2.3.4.  PKCS#5 PBKDF2 Authenticator

     The PKCS#5 PBKDF2 authenticator is an implementation of RSA Labs'
     Public Key Cryptographic Standards #5 v2.1 Password Based Key
     Derivation Function #2. [pkcs5] In this scheme, the string '$1$' is
     prepended to the password is used in conjunction with a salt,
     iteration count and hash function to generate an authenticator.  This
     revision of the Virtual World Region Agent Protocol specification
     requires the use of SHA256 with the PKCS#5 PBKDS2 authenticator.  It
     also requires the presence of the algorithm key, and that the value
     of this key be the string 'sha256'.  Note that future versions of
     this specification may ALLOW or REQUIRE the use of other
     cryptographic hash functions.

     As with the Challenge-Response authenticator, the authentication
     service MUST include the salt and iteration count in its response to
     an authentication request that is made without a secret item.
     Conforming authentication services may include a duration in their
     response indicating the number of seconds for which the salt and
     iteration count will be valid.

  2.4.  Response

     The response to the agent login message is notice of one of seven
     "conditions":

     o  authentication success

     o  maintenance deferred success

     o  authentication non-success

     o  authentication failure

     o  "user intervention required" failure, and

     o  "non-specific" failure.

     The specification recognizes three "non-failure" responses:

  2.4.1.  Success

     Upon success, the authentication service will respond with a message
     containing the "Agent Seed Capability".  Receipt of this capability
     indicates authentication was successful.  This capability is then
     used for further interactions with the system.





  Chu, et al.              Expires January 6, 2011                [Page 6]


  Internet-Draft            VWRAP Authentication                 July 2010


  2.4.2.  Maintenance Deferred Success

     This condition indicates per-agent (or per-account) login-time
     maintenance is being performed.  It is not an error.  The response
     includes a maintenance cap the client application should use to get
     information about currently executing maintenance.  For more
     information about maintenance, see the Maintenance section below.

  2.4.3.  Authentication Non-Success

     Authentication Non-Success is the response given when a client
     queries the agent domain for agent-specific or account-specific
     authentication parameters.  In that it is the expected response to
     such a query, it is not an error or exception.  But it is not an
     indication of successful authentication.

  2.5.  Errors and Exceptions

  2.5.1.  Authentication Failure

     An authentication failure indicates the client application did not
     provide enough information to authenticate the account or the agent.

  2.5.2.  User Intervention Required Failure

     This error indicates that the authentication service cannot
     authenticate the user for non-technical reasons.  The protocol does
     not attempt to describe why, or imply recovery from this error.  But
     an authentication service that returns this response MUST provide a
     URL containing a message describing the condition leading to the
     error and remediation, if known.

  2.5.3.  Non Specific Failure

     This error indicates some other error exists which does not fall into
     one of the previous conditions.

  2.6.  Preconditions

  2.6.1.  Client Preconditions

     It is generally assumed that before a user attempts to log into an
     authentication service, they will not be actively connected to that
     service.

     It is also assumed that the user has registered their account; user
     registration is outside the scope of this specification.




  Chu, et al.              Expires January 6, 2011                [Page 7]


  Internet-Draft            VWRAP Authentication                 July 2010


     The client application SHOULD present the authentication service's
     Terms of Service and Critical Messages and allow a user to accept or
     decline them prior to attempting to authenticate.

  2.6.2.  Authentication Service Preconditions

     If the authentication service requires users to read and agree to the
     Terms of Service or acknowledge receipt of Critical Messages prior to
     authentication, it must maintain a record of which accounts and
     agents have accepted and acknowledged these items.

     Authentication services that support the concept of "suspension" or
     "disablement" should also maintain a record of which accounts and
     agents are suspended or disabled.

  2.7.  Postconditions

  2.7.1.  Client Postconditions

     Following successful authentication, the client application SHOULD
     note that the agent has been authenticated to the authentication
     service.  The Virtual World Region Agent Protocol is NOT stateless.

  2.7.2.  Authentication Service Postconditions

     After an account is authenticated, a seed capability is allocated for
     the agent.  The authentication service SHOULD maintain the
     association between the account and the seed capability so it may be
     re-used if the client attempts to re-authenticate the user before the
     capability expires.

  2.8.  Side Effects

     The authentication service SHOULD maintain the "presence" state of an
     agent.  This state should include the agent's seed capability.  If a
     previously authenticated and "present" agent re-authenticates
     successfully, the authentication service MAY return the same seed
     capability.

     After successful authentication, it is expected the client will issue
     a request on the seed capability.  To defend against potential Denial
     of Service attacks against the authentication service, the
     authentication service MAY define a timeout period for the seed
     capability.  If the timeout period expires without a request being
     made against the seed capability, that seed capability will expire.
     Successful authentication of an agent who is "not present" has the
     effect of starting this timer.




  Chu, et al.              Expires January 6, 2011                [Page 8]


  Internet-Draft            VWRAP Authentication                 July 2010


     The Challenge-Response Authenticator is intended to be used with a
     new, randomly generated salt for each authentication request.  If the
     authentication service supports the Challenge-Response authentication
     scheme, it must maintain the "most recently generated salt" for some
     period of time (generally until the expiration of the duration period
     given in the authentication non-success response.)

     After the salt has "timed out" following an unsuccessful Challenge-
     Response authentication request, the authentication service MUST NOT
     allow the use of a previous or fixed salt value.  That is, it is not
     correct, after the salt has expired, to use a null, fixed or previous
     salt.  The authentication service MUST generate a new salt and return
     it to the client application.  An unsuccessful authentication request
     with the Challenge-Response scheme also has the side effect of
     starting the salt duration timer.  When this timer expires, the
     authentication service MUST NOT allow authentication with previously
     generated salts.

  2.9.  Sequence of Events

     It is possible for an authentication request to occur in conditions
     where multiple errors or exceptions COULD be returned.  As the
     protocol does not support reporting multiple failure conditions, the
     following sequence is provided to determine the priority of failure
     conditions.  This sequence of events is motivated by the following
     principles:

     o  The authentication service should leak no account status
        information to an unauthenticated user.

     o  Maintenance should occur after successful authentication and
        before account status checking in case maintenance involves the
        representation of these states by the authentication service.

     o  The authentication service should check for "administrative
        issues" after maintenance is complete.

     The sequence for authentication is as follows.  At the first error,
     the system produces an appropriate error response.

     1.  If the authenticator provided is a Challenge-Response or PKCS#5
         PBKDF2 type AND a secret is not included, the system returns an
         authentication non-success response.

     2.  The secret and optional authentication parameters are used to
         verify the client is in possession of the shared secret.  If
         authentication is unsuccessful, an authentication failure
         response is returned.



  Chu, et al.              Expires January 6, 2011                [Page 9]


  Internet-Draft            VWRAP Authentication                 July 2010


     3.  If per-user login-time maintenance must be performed, the
         authentication service allocates a maintenance capability and
         returns it to the client application as a maintenance deferred
         success response.

     4.  If an "administrative issue" exists such as the user is
         suspended, banned, must agree to the terms of service or read
         critical messages, the system returns a "user intervention
         required" response, providing a URL referencing a web resource
         explaining the administrative issue and describing remediation
         steps.

     5.  Check to see if the authenticated agent is associated with an
         agent seed capability already.  If so, return a success response
         referencing that seed capability.

     6.  Start the seed capability timer.  Allocate an agent seed
         capability and return it to the client application via a success
         response.

  2.10.  Interface

     The following text describes the interface description of the
     agent_login messages.[I-D.ietf-vwrap-type-system]

     ; authenticators

     ; hashed password authenticator

     &authenticator = {
       type: 'hash',           ; identifies this as "hashed" type
       algorithm: 'md5',       ;
       secret: binary          ; hash of salt prepended to the password;
                               ;   s = h( '$1$' | pw )
     }

     ; challenge response style authenticator

     &authenticator = {
       type: 'challenge',      ; identifies this as a "challenge response"
       algorithm: 'sha256',    ;
       salt: binary,           ; optional - default is 0x24, 0x31, 0x24
       secret: binary          ; hash of the salt prepended to password
                               ;   s = h( salt | h( '$1$' | pw ) )
     }

     ; PKCS#5 PBKDF2 style authenticator




  Chu, et al.              Expires January 6, 2011               [Page 10]


  Internet-Draft            VWRAP Authentication                 July 2010


     &authenticator = {
       type: 'pkcs5pbkdf2',    ; identifies authenticator as PKCS#5 PBKDF2
       algorithm: string,      ; identifier for hash ('md5' or 'sha256')
       salt: binary,           ; optional - default is 0x24, 0x31, 0x24
       count: int,             ; optional - 1 used if not present
       secret: binary          ; hash of the salt prepended to password
                               ; s = pbkdf2( h('$1$' |pw),salt,count,128)
     }

     ; request

     &credential = {
       account_name: string,
       authenticator: &authenticator ; 'hash' 'challenge' or 'pkcs5pbkdf2'
     }

     ; response

     ; successful response

     &response = {
       condition: 'success',
       agent_seed_capability: uri    ; URL of the agent seed cap
     }

     ; authentication failure

     &response = {
       condition: 'key',
       salt: binary,            ; optional - salt for challenge and PKCS5
       count: int,              ; optional - iteration count for PKCS5
       duration: int            ; optional - the duration of the validity
                                ; period of salt and count values in
                                ; seconds
     }

     ; maintenance "non success"

     &response = {
       condition: 'maintenance',
       maintenance_capability: uri,  ; URL of the maintenance cap
       completion: int               ; estimate for maintenance duration
                                     ; (in seconds)
     }

     ; administrative failure

     &response = {



  Chu, et al.              Expires January 6, 2011               [Page 11]


  Internet-Draft            VWRAP Authentication                 July 2010


       condition: 'intervention',
       message: uri                 ; a URI with human-readable text
                                    ; explaining what the user must do to
                                    ; continue
     }

     ; non-specific error

     &response = {
       condition: 'nonspecific',
       message: string              ; a string describing the failure
     }

     ; resource definition

     %% agent_login
     -> &credential
     <- &response


  3.  Login-Time Maintenance (Resource Class)

     An authentication service has the option of performing "per-user,
     login-time maintenance" as part of the authentication sequence.
     Performing maintenance after a user is authenticated and before an
     avatar is "rezzed" in a region has several advantages:

     o  it reduces system-wide downtime

     o  it distributes maintenance across time, and

     o  it consumes computational resources only for those agents who use
        the system

     The authentication service signals it is performing maintenance by
     returning a "Maintenance Capability" instead of a seed capability
     following successful authentication.  The maintenance capability
     represents a finite sequence of transactions performed by the agent
     domain on the user's behalf.  It is expected that maintenance is a
     task that will complete in a "tractable" amount of time.

     The maintenance capability may be queried to retrieve information
     about the transactions that are occurring, including:

     o  a textual description of the maintenance being performed

     o  an estimate for how long the maintenance will take to complete




  Chu, et al.              Expires January 6, 2011               [Page 12]


  Internet-Draft            VWRAP Authentication                 July 2010


  3.1.  Service Location

     The authentication service may provide a maintenance capability to
     the client application in response to successful authentication.
     This capability is communicated as an URL to a web based service that
     accepts network queries.
     'maintenance' capability from

  3.2.  Inputs

     There are no parameters to a maintenance capability request.

  3.3.  Response

     There are three responses to a maintenance capability: a description
     of ongoing maintenance, a new maintenance capability describing
     another sequence of maintenance transactions, or a seed capability.
     These responses are identified with the condition items: 'ongoing',
     'next' and 'complete'.

     The 'ongoing' response to a maintenance capability request includes a
     simple textual description of the maintenance performed, an estimate
     for how long the maintenance is expected to take, and a validity
     duration for the capability.  The estimate for how long maintenance
     will take is provided so client applications may provide feedback to
     the user.  The validity duration gives the viewer a minimum time
     period the authentication service will maintain the maintenance
     capability.

     When the authentication service returns a 'next' response, it
     indicates that the current maintenance is complete, but a new
     maintenance must be performed before the agent may be placed into a
     region.  The 'next' response includes the URL of the next maintenance
     capability as well as an integer describing the minimum time period
     the authentication service will maintain the maintenance capability.

     When an authentication service returns a 'complete' response, it
     indicates that all maintenance is complete.  The response includes
     the agent seed capability that may be used to place the user's avatar
     in a region.  It also includes an item describing the validity period
     for the current maintenance capability.

  3.4.  Interface

     The following text describes the interface description of the
     agent_login messages.





  Chu, et al.              Expires January 6, 2011               [Page 13]


  Internet-Draft            VWRAP Authentication                 July 2010


     &response = {
       condition: 'ongoing',
       description: string,
       duration: int,               ; seconds 'til maintenance is complete
       validity: int                ; seconds 'til this capability expires
     }

     &response = {
       condition: 'next',
       description: string,
       maintenance_capability: uri, ; URL for the next maintenance cap.
       validity: int                ; seconds 'til this capability expires
     }

     &response = {
       condition: 'complete',
       agent_seed_capability: uri,  ; the agent's seed cap
       validity: int                ; seconds 'til this capability expires
     }

     %% maintenance
     <<response


  4.  Security Considerations

     RFC 3552 [RFC3552] describes several aspects to use when evaluating
     the security of a specification or implementation.  We believe most
     common security concerns users of this specification will encounter
     are more appropriately considered as transport, network or link layer
     issues.  However, the following "application security" issues should
     be considered.

     The MD5 cryptographic hash functions has been deprecated and SHOULD
     be used only for compatibility with older applications.

     The use of the hashed password authenticator could result in a replay
     attack if not used in conjunction with an appropriate confidentiality
     preserving transport.  Implementations using the hashed password
     authenticator SHOULD utilize appropriate encryption schemes such as
     TLS [RFC5246] or S/MIME [RFC3851].


  5.  IANA Considerations

     This document has no actions for IANA.





  Chu, et al.              Expires January 6, 2011               [Page 14]


  Internet-Draft            VWRAP Authentication                 July 2010


  6.  References

  6.1.  Normative References

     [I-D.ietf-vwrap-type-system]
                Brashears, A., Hamrick, M., and M. Lentczner, "VWRAP :
                Abstract Type System for the Transmission of Dynamic
                Structured Data", July 2010.

     [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
                April 1992.

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

     [pkcs5]    Kaliski, B., "PKCS #5: Password-Based Cryptography
                Specification Version 2.0".

     [sha256]   United States National Institute of Standards and
                Technology, "Federal Information Processing Standards
                Publication 180-2 (+ Change Notice to include SHA-224)",
                August 2002.

  6.2.  Informative References

     [I-D.ietf-vwrap-launch]
                Hamrick, M. and J. Hurliman, "VWRAP : Client Application
                Launch Message", draft-ietf-vwrap-launch-00 (work in
                progress), July 2010.

     [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
                Text on Security Considerations", BCP 72, RFC 3552,
                July 2003.

     [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
                Extensions (S/MIME) Version 3.1 Message Specification",
                RFC 3851, July 2004.

     [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                (TLS) Protocol Version 1.2", RFC 5246, August 2008.











  Chu, et al.              Expires January 6, 2011               [Page 15]


  Internet-Draft            VWRAP Authentication                 July 2010


  Authors' Addresses

     Tess Chu
     Linden Research, Inc.
     945 Battery St.
     San Francisco, CA  94111
     US

     Phone: +1 415 243 9000
     Email: tess@lindenlab.com


     Meadhbh Siobhan Hamrick
     P.O. Box 783
     Boulder Creek, CA  95006
     US

     Phone: +1 650 283 0344
     Email: OhMeadhbh@gmail.com


     Mark Lentczner

     Email: mark@glyphic.com



























  Chu, et al.              Expires January 6, 2011               [Page 16]



name: draft-hy-srv6ops-sfc-in-cloud-uc
rev: 00
title: Use Cases and Requirements for Service Function Chaining based on SRv6 in cloud.
time: 2025-04-19T07:05:08Z
group_uri: /api/v1/group/group/1027/
expires: 2025-04-20T03:05:55Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.747016+00:00
source: ietf
source_id: 139765
source_url: https://datatracker.ietf.org/doc/draft-hy-srv6ops-sfc-in-cloud-uc/
doc_status: active
abstract:
  This document outlines the usecase for implementing Service Function
     Chaining(SFC) based on SRv6 in cloud, motivated by the increasing
     demand for collabration between cloud and network.  The capabilities
     of SRv6 in most cloud service are not ready, such as SFC based on
     SRv6.  If we want to realize these capabilities of SRv6 end-to-end,
     virtual routers(VR) can be deployed as an agent which support SRv6 in
     the cloud.

full_text:
  srv6ops                                                       T. He, Ed.
  Internet-Draft                                                X. Yi, Ed.
  Intended status: Informational                              China Unicom
  Expires: 20 April 2025                                   17 October 2024


   Use Cases and Requirements for Service Function Chaining based on SRv6
                                 in cloud.
                    draft-hy-srv6ops-sfc-in-cloud-uc-00

  Abstract

     This document outlines the usecase for implementing Service Function
     Chaining(SFC) based on SRv6 in cloud, motivated by the increasing
     demand for collabration between cloud and network.  The capabilities
     of SRv6 in most cloud service are not ready, such as SFC based on
     SRv6.  If we want to realize these capabilities of SRv6 end-to-end,
     virtual routers(VR) can be deployed as an agent which support SRv6 in
     the cloud.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 20 April 2025.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.










  He & Yi                   Expires 20 April 2025                 [Page 1]


  Internet-Draft   Service Function Chaining based on SRv6    October 2024


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Use cases and scheme  . . . . . . . . . . . . . . . . . . . .   2
       2.1.  SFC based on SRv6 . . . . . . . . . . . . . . . . . . . .   2
     3.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   4
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

  1.  Introduction

     With the rapid development of IPv6 and IPv6 extention protocol, the
     carrier network has basically completed the deployment of them.
     However, in most clouds, IPv4 protocol is still used, and
     IPv6,especially IPv6 extention protocol have not been achieved to
     end-to-end deployment.  In order to promote capabilities of IPv6 and
     IPv6 enhancement into the network end-to-end，such as the capability
     of SFC based on SRv6, we should upgrade the according device and
     system in the cloud.  But considering the upgrading of network
     hardware devices and business systems in the cloud will take a long
     time and cost a lot, we propose a scheme to deploy a VR in the cloud
     to support SRv6 and act as an agent for the application in the cloud,
     so that it can realize the end-to-end SFC based on SRv6.

  2.  Use cases and scheme

  2.1.  SFC based on SRv6

     Nowadays, operators are actively evolving from traditional
     communication service providers to integrated information service
     enterprises.  Operators need to organize a large number of value-
     added services in the cloud such as security service product to meet
     the security requirements of enterprises on the enterprise private
     line.  We can use SFC to achieve this capability and the security
     service can be added and deleted on SFC easily.  At present, SRv6
     capability is the best choice for SFC on the enterprise private line,



  He & Yi                   Expires 20 April 2025                 [Page 2]


  Internet-Draft   Service Function Chaining based on SRv6    October 2024


     but various security services can not support the capability of SRv6
     in the cloud, so we need to use a device as SRv6 agent and interact
     with security services.  Traditionally, we use a router in the
     carrier network as the SRv6 agent to achieve it.  However in this
     scenario, accompany with the increase of the security services, the
     flow between cloud and carrier network multiply.  As shown in the
     Figure 1.

                                    (~~~~~~~~~~~~~~~~~~~~~~~~~)
                                   (           Cloud1          )
                                  (    +--------+  +--------+   )
                                 (     |Service1|  |Service2|    )
                                  (    +--------+  +--------+   )
                                   (      *             *      )
                                    (~~~~~~*~~~~~~~~~~~*~~~~~~)
                                            *    |    *
                                             *   |   *
                                              *  |  *
                                            +--------+
                                            | Router |
                                            +--------+

                                             Figure 1

     And moreover, considering the time and ecomomic costs, we have
     adopted a more flexible approach.In Chinaunicom's network, we deploy
     VR in the cloud as SRv6 agents of security services, so that we can
     decrease the flow between cloud and carrier network, and it can be
     deployed simply and flexibly.  As shown in the Figure 2.






















  He & Yi                   Expires 20 April 2025                 [Page 3]


  Internet-Draft   Service Function Chaining based on SRv6    October 2024


                                    (~~~~~~~~~~~~~~~~~~~~~~~~~)
                                   (           Cloud1          )
                                  (    +--------+  +--------+   )
                                 (     |Service1|  |Service2|    )
                                (      +--------+  +--------+     )
                               (          \              /         )
                                (          \            /         )
                                 (          +---------+          )
                                  (         |   VR    |         )
                                   (        +---------+        )
                                    (~~~~~~~~~~~~~~~~~~~~~~~~~)
                                                 |
                                                 |
                                                 |
                                            +--------+
                                            | Router |
                                            +--------+

                                             Figure 2

  3.  Conclusion

     Generally, in order to introduce SRv6 capability into the cloud,
     realize the end-to-end capability of SFC based on SRv6, we use VR to
     bring quick and flexible update, which benefits the business with
     fast evolution.

  4.  Security Considerations

     TBD.

  5.  IANA Considerations

     TBD.

  Acknowledgements

     TBD.

  Contributors

     TBD.

  Authors' Addresses







  He & Yi                   Expires 20 April 2025                 [Page 4]


  Internet-Draft   Service Function Chaining based on SRv6    October 2024


     Tao He (editor)
     China Unicom
     Beijing
     China
     Email: het21@chinaunicom.cn


     Xinxin Yi (editor)
     China Unicom
     Beijing
     China
     Email: yixx3@chinaunicom.cn







































  He & Yi                   Expires 20 April 2025                 [Page 5]


name: draft-illyes-rep-purpose
rev: 00
title: Robots Exclusion Protocol User Agent Purpose Extension
time: 2025-04-21T07:05:16Z
group_uri: /api/v1/group/group/2440/
expires: 2025-04-21T11:38:10Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/134/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:43.021644+00:00
source: ietf
abstract:
  The Robots Exclusion Protocol defined in [RFC9309] specifies the
     user-agent rule for targeting automatic clients either by prefix
     matching their self-defined product token or by a global rule * that
     matches all clients.

     This document extends [RFC9309] by defining a new rule for targeting
     automatic clients based on the clients' purpose for accessing the
     service.

full_text:
  Network Working Group                                          G. Illyes
  Internet-Draft                                               Google LLC.
  Intended status: Informational                           18 October 2024
  Expires: 21 April 2025


           Robots Exclusion Protocol User Agent Purpose Extension
                        draft-illyes-rep-purpose-00

  Abstract

     The Robots Exclusion Protocol defined in [RFC9309] specifies the
     user-agent rule for targeting automatic clients either by prefix
     matching their self-defined product token or by a global rule * that
     matches all clients.

     This document extends [RFC9309] by defining a new rule for targeting
     automatic clients based on the clients' purpose for accessing the
     service.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://garyillyes.github.io/ietf-rep-purpose/draft-illyes-rep-
     purpose.html.  Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-illyes-rep-purpose/.

     Source for this draft and an issue tracker can be found at
     https://github.com/garyillyes/ietf-rep-purpose.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 21 April 2025.



  Illyes                    Expires 21 April 2025                 [Page 1]


  Internet-Draft                 REP purpose                  October 2024


  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   2
       2.1.  user-agent-purpose  . . . . . . . . . . . . . . . . . . .   3
       2.2.  user-agent-purpose tokens . . . . . . . . . . . . . . . .   3
     3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
     6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
       7.2.  Informative References  . . . . . . . . . . . . . . . . .   4
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   4
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

  1.  Introduction

     (fill in)

  2.  Specification

     We define user-agent-purpose as the new rule with a predefined set of
     values.  The values are registered with IANA at ... Below is an
     Augmented Backus-Naur Form (ABNF) description, as described in
     [RFC5234].

  purpose = *WS "user-agent-purpose" *WS ":" *WS purpose-token NL
  purpose-token = "EXAMPLE-PURPOSE-1" /"EXAMPLE-PURPOSE-2" / "EXAMPLE-PURPOSE-3" ; but check IANA for full list
  NL = %x0D / %x0A / %x0D.0A
  WS = %x20 / %x09






  Illyes                    Expires 21 April 2025                 [Page 2]


  Internet-Draft                 REP purpose                  October 2024


  2.1.  user-agent-purpose

     The user-agent-purpose rule is semantically equivalent to the user-
     agent rule defined in Section 2.2.1. of [RFC9309].  As the user-agent
     rule, user-agent-purpose acts as a starter of rule groups.

  2.2.  user-agent-purpose tokens

     The user-agent-purpose token MUST be a substring of the
     identification string that the automatic client sends to the service.
     For example, in the case of HTTP [RFC9110], the purpose token MUST be
     a substring in the User-Agent header, along with the product token.
     Here's an example of a User-Agent HTTP request header with the
     purpose token by the product token:

  User-Agent: Mozilla/5.0 (compatible; ExampleBot/0.1; ExamplePurpose; https://www.example.com/bot.html)

     The purpose token MUST be one of the tokens registered with IANA.
     Unrecognized tokens MAY be discarded by parsers.  Crawlers MUST use
     case-insensitive matching to find the group that matches the purpose
     token and obey the rules of the group.  If there's a group that
     matches the product token of the automatic client, the client SHOULD
     obey that group.  If no matching group exists, crawlers MUST obey the
     group with a user-agent line with the "*" value, if present.  If
     there is more than one group matching the user-agent-purpose, the
     matching groups' rules MUST be combined into one group and parsed
     according to Section X.

  3.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  4.  Security Considerations

     The security considerations are the same as in the parent [RFC9309].

  5.  IANA Considerations

     The vocabulary used as purpose tokens are registered at IANA-URL.

  6.  Examples






  Illyes                    Expires 21 April 2025                 [Page 3]


  Internet-Draft                 REP purpose                  October 2024


  # robots.txt with purpose
  # FooBot and all bots that are crawling for EXAMPLE-PURPOSE-1 are disallowed.
  User-Agent: FooBot
  User-Agent-Purpose: EXAMPLE-PURPOSE-1
  Disallow: /
  # EXAMPLE-PURPOSE-2 crawlers are allowed.
  User-Agent-Purpose: EXAMPLE-PURPOSE-2

  7.  References

  7.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [RFC9309]  Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/rfc/rfc9309>.

  7.2.  Informative References

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

  Acknowledgments

     TODO acknowledge.

  Author's Address

     Gary Illyes
     Google LLC.
     Email: garyillyes@google.com




  Illyes                    Expires 21 April 2025                 [Page 4]


name: draft-vesely-dmarc-mlm-transform
rev: 09
title: Mailing List Manager (MLM) Transformations
time: 2024-11-22T08:05:00Z
group_uri: /api/v1/group/group/1027/
expires: 2024-11-22T11:30:20Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/75/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.755104+00:00
source: ietf
source_id: 99283
source_url: https://datatracker.ietf.org/doc/draft-vesely-dmarc-mlm-transform/
doc_status: active
abstract:
  The widespread adoption of Domain-based Message Authentication,
     Reporting, and Conformance (DMARC) led Mailing List Managers (MLM) to
     rewrite the From: header field as a workaround.  This document
     proposes a method to revert MLM transformations, in order to restore
     the original From: line after reception.

     There are two strategies to undo From: rewriting, author-centric,
     whereby the signing agent takes measures for undoing, and list-
     centric, whereby the MLM does so.  The present method uses the former
     strategy.

full_text:
  Network Working Group                                          A. Vesely
  Internet-Draft                                               21 May 2024
  Intended status: Experimental                                           
  Expires: 22 November 2024


                 Mailing List Manager (MLM) Transformations
                    draft-vesely-dmarc-mlm-transform-09

  Abstract

     The widespread adoption of Domain-based Message Authentication,
     Reporting, and Conformance (DMARC) led Mailing List Managers (MLM) to
     rewrite the From: header field as a workaround.  This document
     proposes a method to revert MLM transformations, in order to restore
     the original From: line after reception.

     There are two strategies to undo From: rewriting, author-centric,
     whereby the signing agent takes measures for undoing, and list-
     centric, whereby the MLM does so.  The present method uses the former
     strategy.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 22 November 2024.

  Copyright Notice

     Copyright (c) 2024 IETF Trust and the persons identified as the
     document authors.  All rights reserved.








  Vesely                  Expires 22 November 2024                [Page 1]


  Internet-Draft             MLM Transformations                  May 2024


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terms Definitions . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Revertible Transformations  . . . . . . . . . . . . . . . . .   4
       3.1.  Header Transformations  . . . . . . . . . . . . . . . . .   4
       3.2.  Body Transformations  . . . . . . . . . . . . . . . . . .   5
     4.  Robustness of DKIM Signatures . . . . . . . . . . . . . . . .   5
     5.  Outline of a Reverting Verifier . . . . . . . . . . . . . . .   7
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
       7.1.  Provisional Message Header Field Names  . . . . . . . . .  10
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
     Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  13
       A.1.  Single-part plain text  . . . . . . . . . . . . . . . . .  14
       A.2.  Multipart added . . . . . . . . . . . . . . . . . . . . .  14
       A.3.  Multipart wrapped . . . . . . . . . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

     Domain-based Message Authentication, Reporting, and Conformance
     (DMARC) ([RFC7489]) hinges on the alignment of the domain in the
     From: header field with an authenticated identifier.  For that
     reason, mailing list managers (MLMs) that transform messages, however
     lightly, have to rewrite From:, an operation known as From: munging
     or From: rewriting.

     Depending on the kind of mailing list, From: munging can annoy
     participants or not.  For lists paired by web fora, for example, it
     is almost unnoticed.  For classic discussion lists, where personal
     knowledge plays a role, it can become a nuisance as it hinders off-
     list messaging.

     One way to restore the end-to-end nature of the From: header field is
     to revert it to its original value after the message is delivered to
     the final subscriber's mailbox.  This requires that the author domain
     and/ or the MLM save the original value, along with other necessary
     data.  For security reasons, the replacement should only be done
     after verifying the original DKIM signature ([RFC6376]), which can be



  Vesely                  Expires 22 November 2024                [Page 2]


  Internet-Draft             MLM Transformations                  May 2024


     done after reverting MLM transformation.  Indeed, the other
     identifier, SPF ([RFC7208]) cannot be verified on forwarded messages,
     while replacing without verifying would be an easy attack vector.

     The method described here works with MLMs configured to add just a
     footer and/ or a subject tag to the messages that they redistribute,
     which is what "classic" MLMs currently do.  The method requires no
     conferral of trust, but needs author domains to produce "robust"
     signatures (in the sense described in Section 4) which several
     domains do, but not all.

     Other methods to verify signatures after transformations exist,
     [I-D.kucherawy-dkim-transform] and
     [I-D.chuang-mailing-list-modifications], which require MLMs to
     cooperate by annotating what transformations they carry out.  Those
     requirements aim at getting a higher reliability.  However, their
     implementation requires two separate actors, a MLM which records the
     changes and a receiver which undoes them.  Synchronizing them can be
     hard, especially during an initial deploying period characterized by
     the discovery of failure cases.  Having the signer save the data
     necessary to the verifier might seem to still involve two parties,
     but they are typically both implemented by the same code, which
     typically signs outgoing and verifies incoming messages.  That way, a
     mail domain deploying such code can at least verify the messages that
     itself emitted.

     The present method actually originated from an attempt at
     implementing [I-D.kucherawy-dkim-transform] when, after coding was
     completed, a guessing part was added in order to perform tests.

  2.  Terms Definitions

     *Signers* and *verifiers* are defined by DKIM ([RFC6376]).  The use
     of the term *Mailing List Manager*, almost always abbreviated *MLM*
     follows [RFC6377].  A MLM is a kind of *Mediator* in [RFC5598]
     parlance.  It is usually composed of a Message Transfer Agent (MTA)
     with the usual suite of tools plus the mailing list software proper
     and any home brewed additions.

     *Message* is defined in [RFC5322].  It consists of a *header* made up
     of one or more *fields*, and a *body* possibly composed of various
     MIME *entities*, the latter being defined in [RFC2045] and
     companions.

     The term *original* is used here to refer to the Author or parts of
     the Author's message as it was sent out by the author's domain, where
     *Author* is defined in [RFC5598] and [RFC9057].




  Vesely                  Expires 22 November 2024                [Page 3]


  Internet-Draft             MLM Transformations                  May 2024


     We use *colon* (:) to indicate header field names, as in From:,
     Author: and the like.

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8175] when, and only when, they appear in all
     capitals, as shown here.

  3.  Revertible Transformations

     Message modifications can affect the header and/or the body of a
     message.  This document only considers a very limited set of
     transformations, described in the following subsections.  They turn
     out to be revertible.

  3.1.  Header Transformations

  3.1.1.  Subject

     MLM MAY modify the Subject: field by inserting a tag at the beginning
     of its value.  A tag consists of a short text delimited by square
     brackets.  For example:

       Subject: [added tag] Original value of subject

     This transformation is easily reverted by removing the tag.  For
     security reasons, subject tags MUST NOT exceed 20 characters.

     Note that some MLMs carry out further changes to this field.  For
     example:

       Subject: AW: [MLM-tag] German reply subject

     can be transformed to:

       Subject: Re: [MLM-tag] German reply subject

     In a cosmopolitan environment, it may be worth to save a copy of it
     as Original-Subject:.

  3.1.2.  From

     From: rewriting is necessary for DMARC.  That way, the MLM domain
     becomes the primary identifier of a message, in the DMARC sense.  It
     is often achieved by transforming a field like this:

       From: Original User <user@example.com>



  Vesely                  Expires 22 November 2024                [Page 4]


  Internet-Draft             MLM Transformations                  May 2024


     into one like the following:

       From: Original User via MLM <MLM.post@list.example>

     Many MLMs save the original From: in a variety of places, including
     Reply-To:, Cc:, X-Original-From:.  When the original value is known,
     the transformation is revertible.

  3.2.  Body Transformations

     We only consider footer addition.  It MUST be performed in one of
     three ways, according to the format of the original message.

     Single-part plain text
        When the original message is not structured, a footer can be
        appended at the end of the original text.  See example in
        Appendix A.1

     Multipart added
        The footer stands in its own MIME entity, which is appended as the
        last part of an original multipart/mixed structure.  See example
        in Appendix A.2

     Multipart wrapped
        The footer stands in the second entity of a new multipart/mixed
        MIME structure whose first entity consists of the original body.
        See example in Appendix A.3

     The footer begins with a line consisting exclusively of underscore
     ("_", ASCII 95) characters, at least four of them.  Alternatively, a
     footer can consist of the three characters "-- " (dash, dash, space),
     the Usenet signature convention (see for example Section 4.3 of
     [RFC3676]).  For security reasons, the footer MUST belong to an
     entity of Content-Type: text/plain in all cases.  In addition,
     footers cannot exceed 10 lines of text, each shorter than 80
     characters.  If these restrictions are not met, the transformation
     cannot be reverted safely.

  4.  Robustness of DKIM Signatures

     DKIM protocol allows to configure signing very flexibly.  The
     resulting signatures can be more or less "robust", where by that term
     we mean the ability to preserve verifiability through minor
     alterations that don't alter the semantic of the message.  These
     signing requirements can be considered as an alternative to requiring
     MLMs to track the changes they perform.





  Vesely                  Expires 22 November 2024                [Page 5]


  Internet-Draft             MLM Transformations                  May 2024


     First and foremost, Author domains who DKIM-sign outgoing messages
     MUST NOT sign "technical" header fields that MLMs will change,
     namely:

     *  MIME-Version:

     *  Content-Type:

     *  Content-Transfer-Encoding:

     *  Resent-Date:, Resent-From:, Resent-To:, Resent-Cc:

     *  List-Id:, List-Help:, List-Unsubscribe:, List-Subscribe:, List-
        Post:, List-Owner:, List-Archive:

     Not signing Content-Type: implies that author domains MUST NOT use
     the l= signature tag, according to Section 5.4.1 of [RFC6376].

     Second, since MLMs may reflow header fields, DKIM signatures MUST use
     the "relaxed" canonicalization, at least for the header.

     In order to increase reliability, the original value of the signed
     fields SHOULD be mirrored by corresponding fields, From: copied to
     Author:, the other fields to an Original-*: field, that is Reply-To:
     copied to Original-Reply-To:, Subject: to Original-Subject: and so
     forth.  Copying Date: is actually not necessary.  Copying Reply-To:,
     To: and Cc: is only useful if there are multiple recipients and the
     MLM changes their order.  Original-Subject: is necessary if it starts
     with a tag that can be removed when attempting to recover the
     original value; Original-Subject: is defined by [RFC5703], where
     similar considerations hold.

     As said above, author domains who DKIM-sign outgoing messages can
     copy the value of From: to Author:, at least when one or more
     recipients are MLMs.  Additionally, signing the Author: field
     certifies that it was added at the origin.  We can assume that such
     act denotes an interest in this experiment.  Therefore, DMARC
     aggregate results are to be reported to the Author: domain as well,
     in case it differs from the received From: domain.

     MLM transformations are not limited to subject tag and footer.  They
     often alter the encoding, especially for plain text messages.  If the
     original message was encoded as quoted-printable ([RFC2045]) and the
     MLM converts it to base64, there is no way to recover the original
     text, as it is impossible to guess original soft line breaks after
     re-encoding.  Therefore, The quoted-printable encoding MUST NOT be
     used for the body of single-part text/plain messages.




  Vesely                  Expires 22 November 2024                [Page 6]


  Internet-Draft             MLM Transformations                  May 2024


     Base64 is much more robust.  However, single-part text/plain messages
     encoded as base64 MUST follow a constant column width of 76
     characters (which is what most encoders do.)  Since the verifier will
     try and convert base64 content to the default 7bit or 8bit, if the
     original encoding differs, it MUST be advertised by adding a new
     header field as follows:

       Original-Content-Transfer-Encoding: base64

     Original-*: fields with an empty value stand for non-existing
     counterparts.  If the author domain needs to sign empty fields that
     MLMs may add, it is worth declaring them that way.

  5.  Outline of a Reverting Verifier

     This informative section describes the algorithm implemented in a
     mail filter [zdkimfilter].  These kind of filters usually read the
     input message twice —first pass to verify; last pass to rewrite the
     message and insert Authentication-Results: ([RFC8601]).  When
     enabling MLM transformation reversion, there can be a retry pass in
     between those two.  The result is yielded during the SMTP dialogue
     with no noticeable delay.  Implementing reversion changed the
     software from 22730 lines of C code to 26762.  The bulk of such ~18%
     increase is due to the addition of encoding conversion functions.
     Changes involve both verifying and signing functions (see Section 4
     for the latter).

     While reading the header in the first pass, the verifier looks for
     specific fields:

     *  From:

     *  Author:

     *  Original-From:

     *  X-Original-From:

     *  Reply-To:

     *  Cc:

     These are candidates to the original mailbox.  Note that Reply-To:
     and Cc: may contain multiple mailboxes; only the first one is
     considered.






  Vesely                  Expires 22 November 2024                [Page 7]


  Internet-Draft             MLM Transformations                  May 2024


     The verifier also collects the Subject: and any field named
     Original-* that the original signer might have set to ease the
     reversion.  On reaching the end of the header, during the first pass,
     the verifier sorts the candidate original mailboxes according to the
     display name, which MLMs try and keep unaltered.  The best candidate
     is then added to the collected set of Original-* fields.  If the
     Subject: begins with a tag, its version without tag is added to that
     set as well, unless one was already found as Original-Subject:.

     Next, before reading the body, the verifier looks for prospect
     signatures; that is, signatures whose "d=" domain is not aligned with
     SPF credentials ([RFC7208]), List-Post: ([RFC4201]), Sender:, or the
     munged From: (if deemed to have been munged).  If any such signature
     exist, along with MLM or other signatures, then the verifier enables
     parsing the body to look for a footer.

     Reversing verifiers also have to watch out for idiosyncrasies used to
     mask DKIM signatures.  For example, a MLM introduced a header field
     named X-Mailman-Original-DKIM-Signature, because some receivers took
     the habit to downgrade messages with failed signatures, despite
     [RFC6376] recommendation to consider an unauthenticated message
     regardless of whether or not it looks like it was signed.

     Body parsing is done in parallel with body canonicalization during
     the first pass.  For multipart, track top level entities.  Set
     transformation type to "wrapped" if there are exactly two entities,
     "added" otherwise.  However, some lists, perhaps out of
     misconfiguration, insert an empty attachment before the one
     containing the footer.  As it is unlikely that a mail client sends an
     empty attachment, heuristically it may be preferable to just not
     count it.  For single-part, body parsing must avail of encoding
     conversions as needed.  Assume identity encoding, 7bit or 8bit,
     unless otherwise directed by an Original-Content-Transfer-Encoding:
     field.

     At the end of the first pass, the verifier knows how prospect
     signatures did.  Let's recall that DKIM signature verification
     results from two independent operations, steps 3 and 4 in
     Section 6.1.3 of [RFC6376].  The signature in the "b=" tag depends on
     the header, while the body hash in the "bh=" tag depends on the body:

     *  If the signature "b=" did not verify and the set of Original-*
        fields is not empty, then it is worth to try and re-canonicalize
        the header using the values in the set of Original-* fields.

     *  If the body hash "bh=" did not match and a footer was found, then
        it is worth to try and re-canonicalize the body excluding the
        footer.



  Vesely                  Expires 22 November 2024                [Page 8]


  Internet-Draft             MLM Transformations                  May 2024


     None, one, or both of the above operations are performed in the retry
     pass.

     On writing Authentication-Results, if a prospect signature verifies
     after reversion, the verifier must signal this fact.  How to signal
     it is a question of local settings and convenience.  It can consist
     of an apposite reason or comment in Authentication-Results:, or it
     can just write dmarc=pass.  It can also add an Original-From: field
     as a signal that From: can be restored to that value, having
     previously removed or renamed any existing field with the same name.
     For example:

     Original-From: Original Author <author@example.org>
     Authentication-Results: example.com;
       spf=pass smtp.mailfrom=list.example;
       dkim=pass reason="transformed" header.d=example.org;
       dkim=pass (whitelisted) header.d=list.example;
       dmarc=pass header.from=example.org;

     That way, reversion elements can be easily recognized and parsed by
     downstream agents.  It is up to the mail delivery agent (MDA) to
     restore the original value of From:.  The DKIM verifier MUST NOT
     alter the message, except for adding Authentication-Results: and
     possibly Original-From: or another field where the filter saves the
     verified original value of From:.  The MDA can use the presence of
     such field and/ or the reason of dkim=pass as a signal that From: can
     be restored.  The MDA replaces From: just before saving the message
     to the mailbox, after any possible forwarding has been executed.

  6.  Security Considerations

     Rewriting the From: header field is a treacherous modification to
     messages.  It fosters the belief that the display name of a mailbox
     is more true than the angle address.  A belief further consented by
     the tendency to not even display the latter.  Bad actors take
     advantage of this belief by displaying the names of trusted
     institutions paired with trash email addresses hidden between angle
     brackets.  That trick defeats DMARC's purpose.

     It is out of this document's scope to suggest how mail user agents
     (MUAs) could counter phishing by highlighting security indicators
     (for the extent that indicators can actually help preventing phishing
     attacks).  Let's just note that MUAs have to cope with MLMs and
     phishing alike, which makes it hard to devise a pattern to tell apart
     one from the other without getting involved with the reputation of
     the specific domains.





  Vesely                  Expires 22 November 2024                [Page 9]


  Internet-Draft             MLM Transformations                  May 2024


     By safely restoring munged From: to the original value in the MDA,
     that contrast is eliminated.  Then, perhaps, deceptive From: lines
     might become amenable to some kind of efficient indication.

     Of course, MLM role can be played by miscreants as well.  However,
     replaying a signed message, even with revertible transformations, has
     more limits than forging scam messages anew.  Therefore, the risk
     introduced by easing transformation reversion is considerably lower
     than that of not signing, or of keeping DMARC policy at "none".

     An unlikely risk is that of a fake MLM sending messages with Author:
     signed by a broken signature in order to trick a reverting verifier
     into sending fake feedback reports.

     Compared with the use of "l=" tag (Section 8.2 of [RFC6376]), the
     fact that footers are written in plain text removes the main security
     objection about footer additions.  Namely, footers cannot completely
     replace the original content in the end recipient's eyes by
     exploiting lax HTML parsing in the MUA.

     Still, a footer can contain dangerous URLs and deceiving text.  That
     possibility has to be countered by usual mail filtering and savvy
     behavior.

  7.  IANA Considerations

     IANA maintains the "Message Header" registry with several
     subregistries.  IANA is asked to make the assignments set out in the
     following section.

  7.1.  Provisional Message Header Field Names

     IANA is asked to create new entries in the "Provisional Message
     Header Field Names" registry as follows.

















  Vesely                  Expires 22 November 2024               [Page 10]


  Internet-Draft             MLM Transformations                  May 2024


       +===========+============+=============+============+===========+
       | Header    | Applicable | Status      | Author/    | Reference |
       | Field     | Protocol   |             | Change     |           |
       | Name      |            |             | controller |           |
       +===========+============+=============+============+===========+
       | Original- | mail       | provisional | IETF       | this I-D  |
       | Content-  |            |             |            |           |
       | Transfer- |            |             |            |           |
       | Encoding  |            |             |            |           |
       +-----------+------------+-------------+------------+-----------+
       | Original- | mail       | provisional | IETF       | this I-D  |
       | Reply-To  |            |             |            |           |
       +-----------+------------+-------------+------------+-----------+
       | Original- | mail       | provisional | IETF       | this I-D  |
       | Cc        |            |             |            |           |
       +-----------+------------+-------------+------------+-----------+

                                    Table 1

  8.  References

  8.1.  Normative References

     [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part One: Format of Internet Message
                Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
                <https://www.rfc-editor.org/info/rfc2045>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
                DOI 10.17487/RFC5322, October 2008,
                <https://www.rfc-editor.org/info/rfc5322>.

     [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
                "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
                RFC 6376, DOI 10.17487/RFC6376, September 2011,
                <https://www.rfc-editor.org/info/rfc6376>.

     [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
                Message Authentication, Reporting, and Conformance
                (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
                <https://www.rfc-editor.org/info/rfc7489>.





  Vesely                  Expires 22 November 2024               [Page 11]


  Internet-Draft             MLM Transformations                  May 2024


     [RFC8175]  Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
                Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
                DOI 10.17487/RFC8175, June 2017,
                <https://www.rfc-editor.org/info/rfc8175>.

     [RFC9057]  Crocker, D., "Email Author Header Field", RFC 9057,
                DOI 10.17487/RFC9057, June 2021,
                <https://www.rfc-editor.org/info/rfc9057>.

  8.2.  Informative References

     [RFC3676]  Gellens, R., "The Text/Plain Format and DelSp Parameters",
                RFC 3676, DOI 10.17487/RFC3676, February 2004,
                <https://www.rfc-editor.org/info/rfc3676>.

     [RFC4201]  Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
                in MPLS Traffic Engineering (TE)", RFC 4201,
                DOI 10.17487/RFC4201, October 2005,
                <https://www.rfc-editor.org/info/rfc4201>.

     [RFC5703]  Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
                Tests, Iteration, Extraction, Replacement, and Enclosure",
                RFC 5703, DOI 10.17487/RFC5703, October 2009,
                <https://www.rfc-editor.org/info/rfc5703>.

     [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
                DOI 10.17487/RFC5598, July 2009,
                <https://www.rfc-editor.org/info/rfc5598>.

     [RFC6377]  Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
                Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
                September 2011, <https://www.rfc-editor.org/info/rfc6377>.

     [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
                Authorizing Use of Domains in Email, Version 1", RFC 7208,
                DOI 10.17487/RFC7208, April 2014,
                <https://www.rfc-editor.org/info/rfc7208>.

     [RFC7960]  Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky,
                E., Ed., and K. Andersen, Ed., "Interoperability Issues
                between Domain-based Message Authentication, Reporting,
                and Conformance (DMARC) and Indirect Email Flows",
                RFC 7960, DOI 10.17487/RFC7960, September 2016,
                <https://www.rfc-editor.org/info/rfc7960>.







  Vesely                  Expires 22 November 2024               [Page 12]


  Internet-Draft             MLM Transformations                  May 2024


     [RFC8601]  Kucherawy, M., "Message Header Field for Indicating
                Message Authentication Status", RFC 8601,
                DOI 10.17487/RFC8601, May 2019,
                <https://www.rfc-editor.org/info/rfc8601>.

     [I-D.kucherawy-dkim-transform]
                Kucherawy, M., "Recognized Transformations of Messages
                Bearing DomainKeys Identified Mail (DKIM) Signatures",
                Work in Progress, Internet-Draft, draft-kucherawy-dkim-
                transform-02, 5 July 2020,
                <https://datatracker.ietf.org/doc/html/draft-kucherawy-
                dkim-transform-02>.

     [I-D.chuang-mailing-list-modifications]
                Chuang, W., "Tolerating Mailing-List Modifications", Work
                in Progress, Internet-Draft, draft-chuang-mailing-list-
                modifications-04, 20 February 2024,
                <https://datatracker.ietf.org/doc/html/draft-chuang-
                mailing-list-modifications-04>.

     [zdkimfilter]
                "zdkimfilter", <https://www.tana.it/sw/zdkimfilter/>.

  Appendix A.  Examples

     In the examples that follow, the first character of each wrapped line
     of DKIM-Signature: fields should be a TAB.  For editorial reasons, it
     is rendered as four spaces.  While visually there is little
     difference, those signatures won't verify unless replacing them with
     a TAB.

     To verify the examples, public keys can be set as follows:

     s._domainkey.example.com IN TXT ( "v=DKIM1; g=*; k=rsa; "
     "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqlye7m5zLLXoIpBp2OO05LNMqK"
     "u0zKowoHOpyRpviOVqOaNCk5uZ+wY00JwrKbt5u1G1ghuXsFkFkl0h00LBurz7ivyZH"
     "3LohSWOZ8okgR+8kuGu9GHtQ+MqgRd16tlCF8PlWS2kGaBQKua1zk+ZCDwFy82Uo5G2"
     "1nu/+Nn2sUwIDAQAB" )

     s._domainkey.lists.example IN TXT ( "v=DKIM1; k=rsa; "
     "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDgnLb2TZ6KECBMBo9ZLqDFt4ZBz"
     "NHFrgBj/LVJVFU8IQP8uH4G8Pj0mEHRo1qpf0vuFI2HVpe/3NhzkT4Ay/1ZIIsxY754"
     "f2thlhBvKh4AAgZFmzRvA3aZs6Tb/ERmD+a51liEMFaTOmY4mWeLi9wOM51usQ9Q65i"
     "8IP/vjHM3rQIDAQAB" )







  Vesely                  Expires 22 November 2024               [Page 13]


  Internet-Draft             MLM Transformations                  May 2024


  A.1.  Single-part plain text

     Base64 encoding has to be decoded in order to locate the footer.  The
     original encoding was text/plain, this can be inferred by the
     verifier from the absence of an Original-Content-Transfer-Encoding:
     field.  The original body hash will match after decoding and removing
     the footer.  Note that an "l=" tag couldn't have done the trick in
     this case.

     Received: from lists.example by subscriber.example.org with ESMTP
     DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.example; s=s;
         t=1603901305; bh=MjC5ikx26j8beyDJiz7Rk/4W+ppdGOmqh6koz0gLa8o=;
         h=Date:From:To:Subject;
         b=PNIYHGd7aytHEvew44WRpSfl4Py3c/9mKjovvQ1ps/xdpkl1/z+gWeu8e8ZmR7gdE
          iT2TsJ7ni3Lfp5oUpGCko5MvCoqcKX7Zmq3CmXTxRTwwvVZrAp/ir8UTvG+rJFnyEZ
          Yi3dSTX4rKe2LotyLkqcs+/uXaWEADbqcBp/9iHo=
     Received: from mail.example.com by lists.example with ESMTP
     DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=s;
         t=1603889142; bh=hrDXocZNPy1+eUFYIk1PVRKa6mUMb8+ql9CFNABacww=;
         h=Date:From:To:Subject;
         b=YFLwvvW5bGbE5HpJwBM1JoL1F9b8AxdVFlwE/vOkL0p/pPpr7g9KnPXqwoEXZgFI0
          /kkTHK/Afy4gaWZQfwDZ77LuxYSMFjwpNorSc0YEGzHYzLCN7rL1e+xE7B7kOCThiq
          ebaMdcaHeZF6QUmWcUkEj8LVkxrvWi+bTzd3RnaA=
     Original-From: Author <user@example.com>
     Received: from mua.example.com by mail.example.com with ESMTPA
     Message-ID: <123456@author.example>
     Date: Mon, 28 Oct 2020 13:12:55 +0100
     From: Author <user@example.com>
     MIME-Version: 1.0
     To: MLM@lists.example
     Subject: [example] Check simple MLM message
     Content-Type: text/plain; charset=us-ascii
     Content-Transfer-Encoding: base64

     VGhpcyBpcyBhIHBsYWluIHRleHQgbWVzc2FnZSBzdWJtaXR0ZWQgdG8gYSBtYWlsaW5nIGxpc3Qu
     ClRoZSBtYWlsaW5nIGxpc3QgaXMgZXhwZWN0ZWQgdG8gYWRkIGEgZm9vdGVyIGFuZCBhIHN1Ympl
     Y3QgdGFnLgoKQmVzdApBdXRob3IKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
     X19fX18KdGhpcyBtZXNzYWdlIHdhcyBtb2RpZmllZCBieSBNTE0gZXhhbXBsZQphZGRpbmcgdGhp
     cyBmb290ZXIgYW5kIHRoZSBzdWJqZWN0IHRhZwoobm90ZSB0aGF0IGw9IGlzIG5vdCBzZXQpCg==

  A.2.  Multipart added

     When the original message has a MIME structure, MLMs can append an
     entity.







  Vesely                  Expires 22 November 2024               [Page 14]


  Internet-Draft             MLM Transformations                  May 2024


     Received: from lists.example by subscriber.example.org with ESMTP
     DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.example; s=s;
         t=1603974193; bh=sEPYSlJlh90leqy5+63oPn1iU+9P684R92cZHXa9ENw=;
         h=Date:From:To:Subject;
         b=fTSAMcaEatofQCuAeUhlTXmVl5j9bPbwWgc84NWtoSt5zT+SSNp37DTzhYIGHozEk
          bpldArGQ+GygJE1b2witi6NctBd1O/xsUwDcJQxDXkF63QlCcalbKWypHZOhRqncUQ
          zgUzdcuYgqTYMJ0NoTP8fqu0HdgmjD2LJXjV3pVI=
     Old-Authentication-Results: lists.example;
       dkim=pass header.d=example.com
     Received: from mail.example.com by lists.example with ESMTP
     DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=s;
         t=1603973996; bh=eWqyE53pjRVCFGyHY1zGQTkCEvucN1vNN4cTcWk90WU=;
         h=Date:From:To:Subject;
         b=LGP1M3IX6XORfLs8HRLCFOcymzsPn+8+ljgQlmeNlCC/2Cl1+aBDCIEnzWI0pceCb
          zg32vFfEeryvRDHB1L1K4rrKCEznvO0J3p1xkUPEWpSpzxUGw+PK9KA9ePZ5qdz7cI
          /hXf7zjebznNdDQJnxajf7QHnx1tXmxijsJ1jiGQ=
     Old-Authentication-Results: example.com; auth=pass (details omitted)
     Original-From: Author <user@example.com>
     Received: from mua.example.com by mail.example.com with ESMTPA
     Message-ID: <123456@author.example>
     Date: Mon, 28 Oct 2020 13:12:55 +0100
     From: Author via MLM <MLM@lists.example>
     MIME-Version: 1.0
     To: MLM@lists.example
     Subject: [example] Check simple MLM message
     Content-Type: multipart/mixed; boundary=original-boundary

     Original preamble must be preserved!

     --original-boundary
     Content-Type: text/plain; charset=us-ascii
     Content-Transfer-Encoding: 7bit

     This is a plain text message submitted to a mailing list.
     The mailing list is expected to add a footer and a subject tag.

     Best
     Author

     --original-boundary
     Content-Type: image/png
     Content-Transfer-Encoding: base64

     iVBORw0KGgoAAAANSUhEUgAAAAYAAAAGCAYAAADgzO9IAAAABHNCSVQICAgIfAhkiAAAAAlwSFlz
     AAAHKgAAByoB49HU1wAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAB+SURB
     VAiZNcGxDYUgAEXRhxTMYWLFVlDTOAUjOIEzWDqEC1igCQ0LSLi/+ueotUZKieu6uO+bdV2ptaLz
     PDHGsG0b+74jieM40Pd91Fr5K6UAMC3LImutxhgaY8g5p3meNcUYFULQ+756nkchBMUYpd47OWe8
     93jvyTnTe+cHXqRZbKSV4EoAAAAASUVORK5CYII=



  Vesely                  Expires 22 November 2024               [Page 15]


  Internet-Draft             MLM Transformations                  May 2024


     --original-boundary
     Content-Tyep: text/plain

     ________________________________________
     this message was modified by MLM example
     adding this footer and the subject tag
     (note that l= cannot work in this case)

     --original-boundary--

  A.3.  Multipart wrapped

     When the original body is multipart/alternative, MLMs have to wrap
     the whole body into the first entity of a multipart/mixed structure.
     Indeed, appending an entity to a multipart/alternative would result
     in it either hiding or being hidden by the existing ones.

     Received: from lists.example by subscriber.example.org with ESMTP
     DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lists.example; s=s;
         t=1603962061; bh=n4/RahgnfVg7htgJtCr7TwEW4eKA1O5oiNaQFA5HU+A=;
         h=Date:From:To:Subject;
         b=RJlq/Fu40AC1hdJfljd+KPU69Vq2M7capbGQyEMhDWvaN7xDPJdXotwnTwiz91iZY
          5W3ITY7YXKHsWweLxu1Rph3ST3bbYQ1cifztpmtu4VPifBkm9MAe7OMDLHhk5ua9YL
          VzJOsXieiIw5a8JhOsr6F/05/K05kNiEXvuLgKd8=
     Old-Authentication-Results: lists.example;
       dkim=pass header.d=example.com
     Received: from mail.example.com by lists.example with ESMTP
     DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=example.com; s=s;
         t=1603961679; bh=XiCPbOV1vcu2Q2TyEUOuT4SMun2AjYj/Va6KRPa1lv0=;
         h=Date:From:To:Subject;
         b=gvM5grV2dbtinFMLcExv+gMATILzY+c8RY7QPVBJSFohH5HMgOLwrgSH8uwOcZxq0
          FoXtBcHnukonqo97l8nY0faHi0Dp0LAmqn9e4ijwXw9IWwhFuUiCwICRaLEzrNUVBN
          TWtzkQKnHpEXnPGBD7Q9f924mBe+eZsDyRc41ZvQ=
     Old-Authentication-Results: example.com; auth=pass (details omitted)
     Original-From: Author <user@example.com>
     Received: from mua.example.com by mail.example.com with ESMTPA
     Message-ID: <123456@author.example>
     Date: Mon, 28 Oct 2020 13:12:55 +0100
     From: Author via MLM <MLM@lists.example>
     MIME-Version: 1.0
     To: MLM@lists.example
     Subject: [example] Check simple MLM message
     Content-Type: multipart/mixed; boundary=MLM-boundary

     This is the MLM preamble, not signed by Author.

     --MLM-boundary
     Content-Type: multipart/alternative; boundary=original-boundary



  Vesely                  Expires 22 November 2024               [Page 16]


  Internet-Draft             MLM Transformations                  May 2024


     Original preamble must be preserved!

     --original-boundary
     Content-Type: text/plain;

     This is a plain text message submitted to a mailing list.
     The mailing list is expected to add a footer and a subject tag.

     Best
     Author

     --original-boundary
     Content-Type: text/html;

     <p>This is a plain text message submitted to a mailing list.
     The mailing list is expected to add a footer and a subject tag.

     <p>Best<br>
     Author<br>

     --original-boundary--

     Original epilogue

     --MLM-boundary
     Content-Type: text/plain

     ________________________________________
     this message was modified by MLM example
     adding this footer and the subject tag
     (note that l= is not set)

     --MLM-boundary--

     MLM epilogue

  Author's Address

     Alessandro Vesely
     v. L. Anelli 13
     20122 Milano MI
     Italy
     Email: vesely@tana.it








  Vesely                  Expires 22 November 2024               [Page 17]


