Message Tracking Query Protocol
RFC 3887
| Document | Type | RFC - Proposed Standard (September 2004) Errata | |
|---|---|---|---|
| Author | Tony Hansen | ||
| Last updated | 2020-01-21 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Scott Hollenbeck | |
| Send notices to | (None) |
RFC 3887
Internet Engineering Task Force R. Wilton, Ed.
Internet-Draft D. Ball
Intended status: Informational T. Singh
Expires: July 24, 2017 Cisco Systems
S. Sivaraj
Juniper Networks
January 20, 2017
Sub-interface VLAN YANG Data Models
draft-ietf-netmod-sub-intf-vlan-model-00
Abstract
This document defines YANG modules to add support for classifying
traffic received on interfaces as Ethernet/VLAN framed packets to
sub-interfaces based on the fields available in the Ethernet/VLAN
frame headers. These modules allow IETF forwarding protocols (such
as IPv6 and VPLS) to interoperate with VLAN tagged traffic orginated
from an IEEE 802.1Q compliant bridge. Primarily the classification
is based on VLAN identifiers in the 802.1Q VLAN tags, but the model
also has support for matching on some other layer 2 frame header
fields and is designed to be extensible to match on other arbitrary
header fields.
The model differs from an IEEE 802.1Q bridge model in that the
configuration is interface/sub-interface based as opposed to being
based on membership of an 802.1Q VLAN bridge.
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 July 24, 2017.
Wilton, et al. Expires July 24, 2017 [Page 1]
Internet-Draft Sub-interface VLAN YANG January 2017
Copyright Notice
Copyright (c) 2017 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
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Interoperability with IEEE 802.1Q compliant bridges . . . 4
2.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 4
3. L3 Interface VLAN Model . . . . . . . . . . . . . . . . . . . 5
4. Flexible Encapsulation Model . . . . . . . . . . . . . . . . 5
5. L3 Interface VLAN YANG Module . . . . . . . . . . . . . . . . 7
6. Flexible Encapsulation YANG Module . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10.1. if-l3-vlan.yang . . . . . . . . . . . . . . . . . . . . 20
10.2. flexible-encapsulation.yang . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Comparison with the IEEE 802.1Q Configuration Model 24
A.1. Sub-interface based configuration model overview . . . . 24
A.2. IEEE 802.1Q Bridge Configuration Model Overview . . . . . 25
A.3. Possible Overlap Between the Two Models . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
Wilton, et al. Expires July 24, 2017 [Page 2]
Internet-Draft Sub-interface VLAN YANG January 2017
1. Introduction
This document defines two YANG [RFC6020] modules that augment the
encapsulation choice YANG element defined in Interface Extensions
YANG [I-D.ietf-netmod-intf-ext-yang] and the generic interfaces data
model defined in [RFC7223]. The two modules provide configuration
nodes to support classification of Ethernet/VLAN traffic to sub-
interfaces, that can have interface based feature and service
configuration applied to them.
The purpose of these models is to allow IETF defined forwarding
protocols, such as IPv6 [RFC2460], Ethernet Pseudo Wires [RFC4448]
and VPLS [RFC4761] [RFC4762] to be configurable via YANG when
interoperating with VLAN tagged traffic received from an IEEE 802.1Q
compliant bridge.
In the case of layer 2 Ethernet services, the flexible encapsulation
module also supports flexible rewriting of the VLAN tags contained
the in frame header.
For reference, a comparison between the sub-interface based YANG
model documented in this draft and an IEEE 802.1Q bridge model is
described in Appendix A.
In summary, the YANG modules defined in this internet draft are:
if-l3-vlan.yang - Defines the model for basic classification of
VLAN tagged traffic to L3 transport services
flexible-encapsulation.yang - Defines the model for flexible
classification of Ethernet/VLAN traffic to L2 transport services
1.1. 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 RFC 2119 [RFC2119].
Sub-interface: A sub-interface is a small augmentation of a regular
interface in the standard YANG module for Interface Management that
represents a subset of the traffic handled by its parent interface.
As such, it supports both configuration and operational data using
any other YANG models that augment or reference interfaces in the
normal way. It is defined in Interface Extensions YANG
[I-D.ietf-netmod-intf-ext-yang].
Wilton, et al. Expires July 24, 2017 [Page 3]
Internet-Draft Sub-interface VLAN YANG January 2017
1.2. Tree Diagrams
A simplified graphical representation of the data model is used in
this document. The meaning of the symbols in these diagrams is as
follows:
o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" means state data (read-only).
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list or leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
2. Objectives
The primary aim of the YANG modules contained in this draft is to
provide the core model that is required to implement VLAN transport
services on router based devices that is fully compatible with IEEE
802.1Q complaint bridges.
A secondary aim is for the modules to be structured in such a way
that they can be cleanly extended in future.
2.1. Interoperability with IEEE 802.1Q compliant bridges
The modules defined in this document are designed to fully
interoperate with IEEE 802.1Q compliant bridges. In particular, the
models are restricted to only matching, adding, or rewriting the
802.1Q VLAN tags in frames in ways that are compatible with IEEE
802.1Q compliant bridges.
2.2. Extensibility
The modules are structured in such a way that they can be sensibly
extended. In particular:
The tag stack is represented as a list to allow a tag stack of
more than two tags to be supported if necessary in future.
The tag stack list elements allow other models, or vendors, to
include additional forms of tag matching and rewriting. The
Wilton, et al. Expires July 24, 2017 [Page 4]
Internet-Draft Sub-interface VLAN YANG January 2017
intention, however, is that it should not be necessary to have any
vendor specific extensions to any of the YANG models defined in
this document to implement standard Ethernet and VLAN services.
3. L3 Interface VLAN Model
The L3 Interface VLAN model provides appropriate leaves for
termination of an 802.1Q VLAN tagged segment to a sub-interface based
L3 service. It allows for termination of traffic with up to two
802.1Q VLAN tags.
The "if-l3-vlan" YANG module has the following structure:
augment /if:interfaces/if:interface/if-cmn:encapsulation/
if-cmn:encaps-type:
+--:(vlan)
+--rw vlan
+--rw tags
+--rw tag* [index]
+--rw index uint8
+--rw dot1q-tag
+--rw tag-type dot1q-tag-type
+--rw vlan-id dot1q-vlan-id
4. Flexible Encapsulation Model
The Flexible Encapsulation model is designed to allow for the
flexible provisioning of layer 2 services. It provides the
capability to classify Ethernet/VLAN frames received on an Ethernet
trunk interface to sub-interfaces based on the fields available in
the layer 2 headers. Once classified to sub-interfaces, it provides
the capability to selectively modify fields within the layer 2
headers before the frame is handed off to the appropriate forwarding
code for further handling.
The model supports a common core set of layer 2 header matches based
on the 802.1Q tag type and VLAN Ids contained within the header up to
a tag stack depth of two tags.
The model supports flexible rewrites of the layer 2 frame header for
data frames as they are processed on the interface. It defines a set
of standard tag manipulations that allow for the insertion, removal,
or rewrite of one or two 802.1Q VLAN tags. The expectation is that
manipulations are generally implemented in a symmetrical fashion,
i.e. if a manipulation is performed on ingress traffic on an
interface then the reverse manipulation is always performed on egress
Wilton, et al. Expires July 24, 2017 [Page 5]
Internet-Draft Sub-interface VLAN YANG January 2017
traffic out of the same interface. However, the model also allows
for asymmetrical rewrites, which may be required to implement some
forwarding models (such as E-Tree).
The structure of the model is currently limited to matching or
rewriting a maximum of two 802.1Q tags in the frame header but has
been designed to be easily extensible to matching/rewriting three or
more VLAN tags in future, if required.
The final aim for the model design is for it to be cleanly extensible
to add in additional match and rewrite criteria of the layer 2
header, such as matching on the source or destination MAC address,
PCP or DEI fields in the 802.1Q tags, or the EtherType of the frame
payload. Rewrites can also be extended to allow for modification of
other fields within the layer 2 frame header.
The "flexible-encapsulation" YANG module has the following structure:
augment /if:interfaces/if:interface/if-cmn:encapsulation/
if-cmn:encaps-type:
+--:(flexible) {flexible-encapsulation-rewrites}?
+--rw flexible
+--rw match
| +--rw (match-type)
| +--:(default)
| | +--rw default? empty
| +--:(untagged)
| | +--rw untagged? empty
| +--:(priority-tagged)
| | +--rw priority-tagged
| | +--rw tag-type? dot1q:dot1q-tag-type
| +--:(vlan-tagged)
| +--rw vlan-tagged
| +--rw tag* [index]
| | +--rw index uint8
| | +--rw dot1q-tag
| | +--rw tag-type dot1q-tag-type
| | +--rw vlan-id union
| +--rw match-exact-tags? empty
+--rw rewrite {flexible-rewrites}?
+--rw (direction)?
+--:(symmetrical)
| +--rw symmetrical
| +--rw tag-rewrite {tag-rewrites}?
| +--rw pop-tags? uint8
| +--rw push-tags* [index]
| +--rw index uint8
Wilton, et al. Expires July 24, 2017 [Page 6]
Internet-Draft Sub-interface VLAN YANG January 2017
| +--rw dot1q-tag
| +--rw tag-type dot1q-tag-type
| +--rw vlan-id dot1q-vlan-id
+--:(asymmetrical) {asymmetric-rewrites}?
+--rw ingress
| +--rw tag-rewrite {tag-rewrites}?
| +--rw pop-tags? uint8
| +--rw push-tags* [index]
| +--rw index uint8
| +--rw dot1q-tag
| +--rw tag-type dot1q-tag-type
| +--rw vlan-id dot1q-vlan-id
+--rw egress
+--rw tag-rewrite {tag-rewrites}?
+--rw pop-tags? uint8
+--rw push-tags* [index]
+--rw index uint8
+--rw dot1q-tag
+--rw tag-type dot1q-tag-type
+--rw vlan-id dot1q-vlan-id
augment /if:interfaces/if:interface:
+--rw flexible-encapsulation
+--rw local-traffic-default-encaps
+--rw tag* [index]
+--rw index uint8
+--rw dot1q-tag
+--rw tag-type dot1q-tag-type
+--rw vlan-id dot1q-vlan-id
5. L3 Interface VLAN YANG Module
This YANG module augments the encapsultion container defined in
Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang].
<CODE BEGINS> file "ietf-if-l3-vlan@2016-10-21.yang"
module ietf-if-l3-vlan {
namespace "urn:ietf:params:xml:ns:yang:ietf-if-l3-vlan";
prefix if-l3-vlan;
import ietf-interfaces {
prefix if;
}
import iana-if-type {
prefix ianaift;
}
Wilton, et al. Expires July 24, 2017 [Page 7]
Internet-Draft Sub-interface VLAN YANG January 2017
import ieee802-dot1q-types {
prefix dot1q-types;
}
import ietf-interfaces-common {
prefix if-cmn;
}
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: Lou Berger
<mailto:lberger@labn.net>
WG Chair: Kent Watsen
<mailto:kwatsen@juniper.net>
Editor: Robert Wilton
<mailto:rwilton@cisco.com>";
description
"This YANG module models L3 VLAN sub-interfaces";
revision 2016-10-21 {
description "Latest draft revision";
reference "Internet-Draft draft-wilton-netmod-intf-vlan-yang-04";
}
feature l3-vlan-sub-interfaces {
description
"This feature indicates that the device supports L3 VLAN
sub-interfaces";
}
/*
* Add support for the 802.1Q VLAN encapsulation syntax on layer 3
* terminated VLAN sub-interfaces.
*/
augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
"if-cmn:encaps-type" {
when "../if:type = 'ianaift:l2vlan' and
../if-cmn:transport-layer = 'layer-3'" {
description "Applies only to VLAN sub-interfaces that are
Wilton, et al. Expires July 24, 2017 [Page 8]
Internet-Draft Sub-interface VLAN YANG January 2017
operating at layer 3";
}
if-feature l3-vlan-sub-interfaces;
description "Augment the generic interface encapsulation with an
encapsulation for layer 3 VLAN sub-interfaces";
/*
* Matches a VLAN, or pair of VLAN Ids to classify traffic
* into an L3 service.
*/
case vlan {
container vlan {
description
"Match VLAN tagged frames with specific VLAN Ids";
container tags {
description "Matches frames tagged with specific VLAN Ids";
list tag {
must 'index != 0 or ' +
'count(../tag/index) != 2 or ' +
'dot1q-tag/tag-type = "s-vlan"' {
error-message
"When matching two tags, the outer tag must be of
S-VLAN tag type";
description
"For IEEE 802.1Q interoperability, when matching two
tags, it is required that the outer tag is an
S-VLAN, and the inner tag is a C-VLAN";
}
must 'index != 1 or ' +
'count(../tag/index) != 2 or ' +
'dot1q-tag/tag-type = "c-vlan"' {
error-message
"When matching two tags, the inner tag must be of
C-VLAN tag type";
description
"For IEEE 802.1Q interoperability, when matching two
tags, it is required that the outer tag is an
S-VLAN, and the inner tag is a C-VLAN";
}
key "index";
min-elements 1;
max-elements 2;
description "The tags to match, with the outermost tag to
match with index 0";
leaf index {
Wilton, et al. Expires July 24, 2017 [Page 9]
Internet-Draft Sub-interface VLAN YANG January 2017
type uint8 {
range "0..1";
}
/*
* Only allow matching on an inner tag (at index 1), if
* also matching on the outer tag at the same time.
*/
must ". = 0 or
count(../../tag[index = 0]/index) > 0" {
error-message
"An inner tag can only be matched on when also
matching on an outer tag";
description
"Only allow matching on an inner tag, if also
matching on the outer tag at the same time";
}
description
"The index into the tag stack, outermost tag first";
}
uses dot1q-types:dot1q-tag-classifier;
}
}
}
}
}
}
<CODE ENDS>
6. Flexible Encapsulation YANG Module
This YANG module augments the encapsultion container defined in
Interface Extensions YANG [I-D.ietf-netmod-intf-ext-yang].
This YANG module also augments the interface container defined in
[RFC7223].
<CODE BEGINS> file "ietf-flexible-encapsulation@2016-10-21.yang"
module ietf-flexible-encapsulation {
namespace
"urn:ietf:params:xml:ns:yang:ietf-flexible-encapsulation";
prefix flex;
Wilton, et al. Expires July 24, 2017 [Page 10]
Internet-Draft Sub-interface VLAN YANG January 2017
import ietf-interfaces {
prefix if;
}
import ietf-interfaces-common {
prefix if-cmn;
}
import ieee802-dot1q-types {
prefix dot1q-types;
}
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: Lou Berger
<mailto:lberger@labn.net>
WG Chair: Kent Watsen
<mailto:kwatsen@juniper.net>
Editor: Robert Wilton
<mailto:rwilton@cisco.com>";
description
"This YANG module describes interface configuration for flexible
VLAN matches and rewrites.";
revision 2016-10-21 {
description "Latest draft revision";
reference
"Internet-Draft draft-wilton-netmod-intf-vlan-yang-04";
}
feature flexible-encapsulation-rewrites {
description
"This feature indicates whether the network element supports
flexible Ethernet encapsulation that allows for matching VLAN
ranges and performing independent tag manipulations";
}
feature flexible-rewrites {
description
Wilton, et al. Expires July 24, 2017 [Page 11]
Internet-Draft Sub-interface VLAN YANG January 2017
"This feature indicates whether the network element supports
specifying flexible rewrite operations";
}
feature asymmetric-rewrites {
description
"This feature indicates whether the network element supports
specifying different rewrite operations for the ingress
rewrite operation and egress rewrite operation.";
}
feature tag-rewrites {
description
"This feature indicates whether the network element supports
the flexible rewrite functionality specifying flexible tag
rewrites";
}
/*
* flexible-match grouping.
*
* This grouping represents a flexible match.
*
* The rules for a flexible match are:
* 1. default, untagged, priority tag, or a stack of tags.
* - Each tag in the stack of tags matches:
* 1. tag type (802.1Q or 802.1ad) +
* 2. tag value:
* i. single tag
* ii. set of tag ranges/values.
* iii. "any" keyword
*/
grouping flexible-match {
description "Flexible match";
choice match-type {
mandatory true;
description "Provides a choice of how the frames may be
matched";
case default {
description "Default match";
leaf default {
type empty;
description
"Default match. Matches all traffic not matched to any
other peer sub-interface by a more specific
encapsulation.";
} // leaf default
Wilton, et al. Expires July 24, 2017 [Page 12]
Internet-Draft Sub-interface VLAN YANG January 2017
} // case default
case untagged {
description "Match untagged Ethernet frames only";
leaf untagged {
type empty;
description
"Untagged match. Matches all untagged traffic.";
} // leaf untagged
} // case untagged
case priority-tagged {
description "Match priority tagged Ethernet frames only";
container priority-tagged {
description "Priority tag match";
leaf tag-type {
type dot1q-types:dot1q-tag-type;
description "The 802.1Q tag type of matched priority
tagged packets";
}
}
}
case vlan-tagged {
container vlan-tagged {
description "Matches VLAN tagged frames";
list tag {
must gt; YWJjZGVmZ2gK
S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S:
S: --%%%%
S: Content-Type: message/tracking-status
S:
S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S:
S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: rfc822; user1@example1.com
S: Action: relayed
S: Status: 2.1.9
S: Remote-MTA: dns; smtp.example3.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S:
S: Original-Recipient: rfc822; user2@example1.com
S: Final-Recipient: rfc822; user4@example3.com
S: Action: delivered
S: Status:2.5.0
S:
S: --%%%%--
S: .
Hansen Standards Track [Page 10]
RFC 3887 Message Tracking Query Protocol September 2004
Example #12 Firewall, Hiding System Names Behind the Firewall:
C: TRACK <12345-20010101@example.com> YWJjZGVmZ2gK
S: +OK+ Tracking information follows
S: Content-Type: multipart/related; boundary=%%%%; type=tracking-status
S:
S: --%%%%
S: Content-Type: message/tracking-status
S:
S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S:
S: Original-Recipient: rfc822; user1@example1.com
S: Final-Recipient: rfc822; user1@example1.com
S: Action: relayed
S: Status: 2.1.9
S: Remote-MTA: dns; example2.com
S: Last-Attempt-Date: Mon, 1 Jan 2001 19:15:03 -0500
S:
S: --%%%%
S: Content-Type: message/tracking-status
S:
S: Original-Envelope-Id: 12345-20010101@example.com
S: Reporting-MTA: dns; example2.com
S: Arrival-Date: Mon, 1 Jan 2001 15:15:15 -0500
S:
S: Original-Recipient: rfc822; user2@example1.com
S: Final-Recipient: rfc822; user4@example1.com
S: Action: delivered
S: Status: 2.5.0
S:
S: --%%%%--
S: .
5. COMMENT Command
Syntax:
comment-command = "COMMENT" opt-text CRLF
opt-text = [WSP *(VCHAR / WSP)]
When the client issues the COMMENT command, the MTQP server MUST
respond with a successful response (+OK or +OK+). All optional text
provided with the COMMENT command are ignored.
Hansen Standards Track [Page 11]
RFC 3887 Message Tracking Query Protocol September 2004
6. STARTTLS Command
Syntax:
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF
domain = (sub-domain 1*("." sub-domain))
TLS [TLS] is a popular mechanism for enhancing TCP communications
with confidentiality and authentication. All MTQP servers MUST
implement TLS. However, TLS MAY be disabled by a server
administrator, either explicitly or by failing to install any
certificates for TLS to use. If an MTQP server supports TLS and has
one or more certificates available it MUST include "STARTTLS" in the
option specifications list on protocol startup.
Note: TLS SHOULD be enabled on MQTP servers whenever possible.
The parameter MUST be a fully qualified domain name (FQDN). A client
MUST specify the hostname it believes it is speaking with so that the
server may respond with the proper TLS certificate. This is useful
for virtual servers that provide message tracking for multiple
domains (i.e., virtual hosting).
If the server returns a negative response, it MAY use one of the
following response codes:
"/" "unsupported"
"/" "unavailable"
"/" "tls-in-progress"
"/" "bad-fqdn"
If TLS is not supported, then a response code of "/unsupported"
SHOULD be used. If TLS is not available for some other reason, then
a response code of "/unavailable" SHOULD be used. If a TLS session
is already in progress, then it is a protocol error and "-BAD" MUST
be returned with a response code of "/tls-in-progress". If there is
a mismatch between the supplied FQDN and the FQDN found in the
dNSName field of the subjectAltName extension of the server's
certificate [RFC-X509], then it is a protocol error and "-BAD" MUST
be returned with a response code of "/bad-fqdn".
After receiving a positive response to a STARTTLS command, the client
MUST start the TLS negotiation before giving any other MTQP commands.
If the MTQP client is using pipelining (see below), the STARTTLS
command must be the last command in a group.
Hansen Standards Track [Page 12]
RFC 3887 Message Tracking Query Protocol September 2004
6.1. Processing After the STARTTLS Command
If the TLS handshake fails, the server SHOULD abort the connection.
After the TLS handshake has been completed, both parties MUST
immediately decide whether or not to continue based on the
authentication and confidentiality achieved. The MTQP client and
server may decide to move ahead even if the TLS negotiation ended
with no authentication and/or no confidentiality because most MTQP
services are performed with no authentication and no confidentiality,
but some MTQP clients or servers may want to continue only if a
particular level of authentication and/or confidentiality was
achieved.
If the MTQP client decides that the level of authentication or
confidentiality is not high enough for it to continue, it SHOULD
issue an MTQP QUIT command immediately after the TLS negotiation is
complete.
If the MTQP server decides that the level of authentication or
confidentiality is not high enough for it to continue, it MAY abort
the connection. If it decides that the level of authentication or
confidentiality is not high enough for it to continue, and it does
not abort the connection, it SHOULD reply to every MTQP command from
the client (other than a QUIT command) with a negative "-ERR"
response and a response code of "/insecure".
6.2. Result of the STARTTLS Command
Upon completion of the TLS handshake, the MTQP protocol is reset to
the initial state (the state in MTQP after a server starts up). The
server MUST discard any knowledge obtained from the client prior to
the TLS negotiation itself. The client MUST discard any knowledge
obtained from the server, such as the list of MTQP options, which was
not obtained from the TLS negotiation itself.
At the end of the TLS handshake, the server acts as if the connection
had been initiated and responds with an initial status response and,
optionally, a list of server options. The list of MTQP server
options received after the TLS handshake MUST be different than the
list returned before the TLS handshake. In particular, a server MUST
NOT return the STARTTLS option in the list of server options after a
TLS handshake has been completed.
Both the client and the server MUST know if there is a TLS session
active. A client MUST NOT attempt to start a TLS session if a TLS
session is already active.
Hansen Standards Track [Page 13]
RFC 3887 Message Tracking Query Protocol September 2004
7. QUIT Command
Syntax:
quit-command = "QUIT" CRLF
When the client issues the QUIT command, the MTQP session terminates.
The QUIT command has no parameters. The server MUST respond with a
successful response. The client MAY close the session from its end
immediately after issuing this command (if the client is on an
operating system where this does not cause problems).
8. Pipelining
The MTQP client may elect to transmit groups of MTQP commands in
batches without waiting for a response to each individual command.
The MTQP server MUST process the commands in the order received.
Specific commands may place further constraints on pipelining. For
example, STARTTLS must be the last command in a batch of MTQP
commands.
8.1. Examples
The following two examples are identical:
Example #13 :
C: TRACK <tracking-id> YWJjZGVmZ2gK
S: +OK+ Tracking information follows
S:
S: ... tracking details #1 go here ...
S: .
C: TRACK <tracking-id-2> QUJDREVGR0gK
S: +OK+ Tracking information follows
S:
S: ... tracking details #2 go here ...
S: .
Hansen Standards Track [Page 14]
RFC 3887 Message Tracking Query Protocol September 2004
Example #14 :
C: TRACK <tracking-id> YWJjZGVmZ2gK
C: TRACK <tracking-id-2> QUJDREVGR0gK
S: +OK+ Tracking information follows
S:
S: ... tracking details #1 go here ...
S: .
S: +OK+ Tracking information follows
S:
S: ... tracking details #2 go here ...
S: .
9. The MTQP URI Scheme
9.1. Intended usage
The MTQP URI scheme is used to designate MTQP servers on Internet
hosts accessible using the MTQP protocol. It performs an MTQP query
and returns tracking status information.
9.2. URI Scheme Name
The name of the URI scheme is "mtqp".
9.3. URI Scheme Syntax
An MTQP URI takes one of the following forms:
mtqp://<mserver>/track/<unique-envid>/<mtrk-secret>
mtqp://<mserver>:<port>/track/<unique-envid>/<mtrk-secret>
The first form is used to refer to an MTQP server on the standard
port, while the second form specifies a non-standard port. Both of
these forms specify that the TRACK command is to be issued using the
given tracking id (unique-envid) and authorization secret (mtrk-
secret). The path element "/track/" MUST BE treated case
insensitively, but the unique-envid and mtrk-secret MUST NOT be.
9.3.1. Formal Syntax
This is an ABNF description of the MTQP URI.
mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret
Hansen Standards Track [Page 15]
RFC 3887 Message Tracking Query Protocol September 2004
9.4. Encoding Rules
The encoding of unique-envid is discussed in [RFC-MTRK-ESMTP].
Mtrk-secret is required to be base64 encoded. If the "/", "?" and
"%" octets appear in unique-envid or mtrk-secret, they are further
required to be represented by a "%" followed by two hexadecimal
characters. (The two characters give the hexadecimal representation
of that octet).
10. IANA Considerations
System port number 1038 has been assigned to the Message Tracking
Query Protocol by the Internet Assigned Numbers Authority (IANA).
The service name "MTQP" has been registered with the IANA.
The IANA has also registered the URI registration template found in
Appendix A in accordance with [BCP35].
This document requests that IANA maintain one new registry: MTQP
options. The registry's purpose is to register options to this
protocol. Options whose names do not begin with "vnd." MUST be
defined in a standards track or IESG approved experimental RFC. New
MTQP options MUST include the following information as part of their
definition:
option identifier
option parameters
added commands
standard commands affected
specification reference
discussion
One MTQP option is defined in this document, with the following
registration definition:
option identifier: STARTTLS
option parameters: none
added commands: STARTTLS
standard commands affected: none
specification reference: RFC 3887
discussion: see RFC 3887
Additional vendor-specific options for this protocol have names that
begin with "vnd.". After the "vnd." would appear the reversed domain
name of the vendor, another dot ".", and a name for the option
itself. For example, "vnd.com.example.extinfo" might represent a
Hansen Standards Track [Page 16]
RFC 3887 Message Tracking Query Protocol September 2004
vendor-specific extension providing extended information by the owner
of the "example.com" domain. These names MAY be registered with
IANA.
11. Security Considerations
If the originator of a message were to delegate his or her tracking
request to a third party, this would be vulnerable to snooping over
unencrypted sessions. The user can decide on a message-by-message
basis if this risk is acceptable.
The security of tracking information is dependent on the randomness
of the secret chosen for each message and the level of exposure of
that secret. If different secrets are used for each message, then
the maximum exposure from tracking any message will be that single
message for the time that the tracking information is kept on any
MTQP server. If this level of exposure is too much, TLS may be used
to reduce the exposure further.
It should be noted that message tracking is not an end-to-end
mechanism. Thus, if an MTQP client/server pair decide to use TLS
confidentiality, they are not securing tracking queries with any
prior or successive MTQP servers.
Both the MTQP client and server must check the result of the TLS
negotiation to see whether acceptable authentication or
confidentiality was achieved. Ignoring this step completely
invalidates using TLS for security. The decision about whether
acceptable authentication or confidentiality was achieved is made
locally, is implementation-dependent, and is beyond the scope of this
document.
The MTQP client and server should note carefully the result of the
TLS negotiation. If the negotiation results in no confidentiality,
or if it results in confidentiality using algorithms or key lengths
that are deemed not strong enough, or if the authentication is not
good enough for either party, the client may choose to end the MTQP
session with an immediate QUIT command, or the server may choose to
not accept any more MTQP commands.
A man-in-the-middle attack can be launched by deleting the "STARTTLS"
option response from the server. This would cause the client not to
try to start a TLS session. An MTQP client can protect against this
attack by recording the fact that a particular MTQP server offers TLS
during one session and generating an alarm if it does not appear in
an option response for a later session.
Hansen Standards Track [Page 17]
RFC 3887 Message Tracking Query Protocol September 2004
Similarly, the identity of the server as expressed in the server's
certificate should be cached, and an alarm generated if they do not
match in a later session.
If TLS is not used, a tracking request is vulnerable to replay
attacks, such that a snoop can later replay the same handshake again
to potentially gain more information about a message's status.
Before the TLS handshake has begun, any protocol interactions are
performed in the clear and may be modified by an active attacker.
For this reason, clients and servers MUST discard any knowledge
obtained prior to the start of the TLS handshake upon completion of
the TLS handshake.
If a client/server pair successfully performs a TLS handshake and the
server does chaining referrals, then the server SHOULD attempt to
negotiate TLS at the same (or better) security level at the next hop.
In a hop-by-hop scenario, STARTTLS is a request for "best effort"
security and should be treated as such.
SASL is not used because authentication is per message rather than
per user.
12. Protocol Syntax
This is a collected ABNF description of the MTQP protocol.
mtqp-uri = "mtqp://" authority "/track/" unique-envid "/" mtrk-secret
conversation = command-response *(client-command command-response)
; client side
client-command = track-command / starttls-command / quit-command
/comment-command
track-command = "TRACK" 1*WSP unique-envid 1*WSP mtrk-secret CRLF
mtrk-secret = base64
starttls-command = "STARTTLS" 1*WSP domain *WSP CRLF
domain = (sub-domain 1*("." sub-domain))
quit-command = "QUIT" CRLF
comment-command = "COMMENT" opt-text CRLF
Hansen Standards Track [Page 18]
RFC 3887 Message Tracking Query Protocol September 2004
; server side
command-response = success-response / temp-response / error-response /
bad-response
temp-response = "-TEMP" response-info opt-text CRLF
opt-text = [WSP *(VCHAR / WSP)]
error-response = "-ERR" response-info opt-text CRLF
bad-response = "-BAD" response-info opt-text CRLF
success-response = single-line-success / multi-line-success
single-line-success = "+OK" response-info opt-text CRLF
multi-line-success = "+OK+" response-info opt-text CRLF
*dataline dotcrlf
dataline = *998OCTET CRLF
dotcrlf = "." CRLF
NAMECHAR = ALPHA / DIGIT / "-" / "_"
response-info = *( "/" ( "admin" / "unavailable" / "unsupported"
/ "tls-in-progress" / "insecure" / "tls-required" / 1*NAMECHAR ) )
13. Acknowledgements
The description of STARTTLS is based on [RFC-SMTP-TLS].
Hansen Standards Track [Page 19]
RFC 3887 Message Tracking Query Protocol September 2004
14. References
14.1. Normative References
[RFC-MIME] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies", RFC 2045, November
1996.
[RFC-ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
for Syntax Specifications: ABNF", RFC 2234,
November 1997.
[RFC-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS
RR for specifying the location of services (DNS
SRV)", RFC 2782, February 2000.
[RFC-SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
[RFC-SMTPEXT] Myers, J., "SMTP Service Extension for
Authentication", RFC 2554, March 1999.
[RFC-MTRK-ESMTP] Allman, E. and T. Hansen, "SMTP Service Extension
for Message Tracking", RFC 3885, September 2004.
[RFC-MTRK-MODEL] Hansen, T., "Message Tracking Models and
Requirements", RFC 3885, September 2004.
[RFC-MTRK-TSN] Allman, E., "The Message/Tracking-Status MIME
Extension", RFC 3886, September 2004.
[RFC-URI] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic
Syntax", RFC 2396, August 1998.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
Hansen Standards Track [Page 20]
RFC 3887 Message Tracking Query Protocol September 2004
14.2. Informational References
[BCP35] Petke, R. and I. King, "Registration Procedures
for URL Scheme Names", BCP 35, RFC 2717, November
1999.
[RFC-SHA1] Eastlake, D. and P. Jones, "US Secure Hash
Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC-SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure
SMTP over Transport Layer Security", RFC 3207,
February 2002.
[RFC-X509] Housley, R., Polk, W., Ford, W. and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[POP3] Myers, J. and M. Rose, "Post Office Protocol -
Version 3", STD 53, RFC 1939, May 1996.
[NNTP] Kantor, B. and P. Lapsley, "Network News Transfer
Protocol", RFC 977, February 1986.
Hansen Standards Track [Page 21]
RFC 3887 Message Tracking Query Protocol September 2004
Appendix A. MTQP URI Registration Template
Scheme name: mtqp
Scheme syntax: see section 9.1
Character encoding considerations: see section 9.4
Intended usage: see section 9.3
Applications and/or protocols which use this scheme: MTQP
Interoperability considerations: as specified for MTQP
Security considerations: see section 11.0
Relevant publications: [RFC-MTRK-ESMTP], [RFC-MTRK-MODEL],
[RFC-MTRK-TSN]
Contact: MSGTRK Working Group
Author/Change Controller: IESG
Author's Address
Tony Hansen
AT&T Laboratories
Middletown, NJ 07748
USA
Phone: +1.732.420.8934
EMail: tony+msgtrk@maillennium.att.com
Hansen Standards Track [Page 22]
RFC 3887 Message Tracking Query Protocol September 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hansen Standards Track [Page 23]