Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
draft-ietf-grow-mrt-17

[Ballot discuss]
This is a revised discuss based on -14.

1) addressed in -14

2) addressed in -14

3) addressed in -14

4) addressed in -14

5) The Security Considerations section explore the ramifications of protecting the transport of data in this format (and perhaps even the timing of its availability) to avoid informing an eavesdropper that wishes to mount an attack on one of the protocols being reported on. Pointing to the potential attacks in the security considerations sections of the protocol documents would help.

[Ballot discuss]
This is revised to adopt Tim's discuss position.

1) addressed in -14

2) addressed in -14

3) addressed in -14

4) addressed in -14


still working through the rest

5) The Security Considerations section explore the ramifications of protecting the transport of data in this format (and perhaps even the timing of its availability) to avoid informing an eavesdropper that wishes to mount an attack on one of the protocols being reported on. Pointing to the potential attacks in the security considerations sections of the protocol documents would help.

This is from Tim's discuss:

This is a revised discuss.  I am adding a discuss position for IANA, whose
questions have not been answered.

Original discuss text:

In most cases, redundant types have been deprecated.  However, both TABLE_DUMP
and TABLE_DUMP_V2
were included as currently supported types.  Isn't V2 a
superset of the old TABLE_DUMP type?  Is there a
reason both need to be
supported?  At a minimum, I think the document could be clearer regarding when
each of
these types SHOULD be used.  (TABLE_DUMP_V2 MUST be used if there are 4
byte ASN values... is there
a SHOULD when we don't have 4 byte ASN values?)

[Ballot discuss]
This is revised to adopt Tim's discuss position.

1) addressed in -14

2) addressed in -14

3) addressed in -14

still working through the rest

4) As noted in the Richard Barnes' SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02007.html), some of the information in an MRT object could be considered private, especially given that MRT is commonly used to publish router dumps (e.g., through RouteViews [1]).  For example, BGP neighbors that advertise paths to their peers might not expect these paths to be published in an MRT dump.  There is also a proposed extension to MRT that would add geolocation information about the router and its peers [2].  I would suggest that the document add a brief note that some information contained in MRT dumps might be considered private.  Suggested text based on the above:
"
Some information contained in an MRT data structure might be considered sensitive or private.  For example, a BGP peer that sends a message to an MRT-enabled router might not expect that message to be shared beyond the AS to which it is sent.  The proposed geolocation extension to MRT could reveal the location of an MRT router's peers [I-D.ietf-grow-geomrt].  An organization that intends to use the MRT structure to export routing information beyond the domain where it normally accessible (e.g., publishing MRT dumps for use by researchers) should verify with any peers whose information might be included, and possibly remove sensitive fields.
"

5) The Security Considerations section explore the ramifications of protecting the transport of data in this format (and perhaps even the timing of its availability) to avoid informing an eavesdropper that wishes to mount an attack on one of the protocols being reported on. Pointing to the potential attacks in the security considerations sections of the protocol documents would help.

This is from Tim's discuss:

This is a revised discuss.  I am adding a discuss position for IANA, whose
questions have not been answered.

Original discuss text:

In most cases, redundant types have been deprecated.  However, both TABLE_DUMP
and TABLE_DUMP_V2
were included as currently supported types.  Isn't V2 a
superset of the old TABLE_DUMP type?  Is there a
reason both need to be
supported?  At a minimum, I think the document could be clearer regarding when
each of
these types SHOULD be used.  (TABLE_DUMP_V2 MUST be used if there are 4
byte ASN values... is there
a SHOULD when we don't have 4 byte ASN values?)

[Ballot comment]
This is updated also.

1) Sec 2.4.1: Expand: FSM.

2) Sec 5.1: Isn't it "OSPFv2 Protocol"?  No need to change the type name but (I think) the text referencing 2328 should say OSPFv2.

3) Sec 5.2, para after Figure 3: Should the "may"s and "should" be upper case?

4) Sec 5.2, penultimate paragraph: must or MUST?

5) Sec 5.3: Expand: ASN, NLRI, AS.

6) Sec 5.3, 2nd para: Please reword so that 2119 requirement is not in a "Note".

7) Sec 5.3, 3rd para: r/optional/OPTIONAL

This is from Tim's comment:

Some editorial issues:

Section 4 begins with "The MRT format defines five Informational Type messages."
but only lists two types.  After
a little sleuthing I discovered the other three
types are deprecated.  Perhaps that is worth mentioning in section 4.

In Annex A, some deprecated types (e.g., RPING in section A.2.4) include
information about the format.  In other
cases (e.g., IDRP in A.2.3), this was
omitted.  Is there a reason for the inconsistency?  (Mostly just curious...)

[Ballot discuss]
This is revised to adopt Tim's discuss position.

1) Sec 4 (If the Apps ADs have already said this): Need a normative reference to UTF-8.

2) Sec 5.2: Need a normative reference to IPv4 and IPv6 for their address formats.

3) Sec 5.5: Is there some format for this field?

4) As noted in the Richard Barnes' SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02007.html), some of the information in an MRT object could be considered private, especially given that MRT is commonly used to publish router dumps (e.g., through RouteViews [1]).  For example, BGP neighbors that advertise paths to their peers might not expect these paths to be published in an MRT dump.  There is also a proposed extension to MRT that would add geolocation information about the router and its peers [2].  I would suggest that the document add a brief note that some information contained in MRT dumps might be considered private.  Suggested text based on the above:
"
Some information contained in an MRT data structure might be considered sensitive or private.  For example, a BGP peer that sends a message to an MRT-enabled router might not expect that message to be shared beyond the AS to which it is sent.  The proposed geolocation extension to MRT could reveal the location of an MRT router's peers [I-D.ietf-grow-geomrt].  An organization that intends to use the MRT structure to export routing information beyond the domain where it normally accessible (e.g., publishing MRT dumps for use by researchers) should verify with any peers whose information might be included, and possibly remove sensitive fields.
"

5) The Security Considerations section explore the ramifications of protecting the transport of data in this format (and perhaps even the timing of its availability) to avoid informing an eavesdropper that wishes to mount an attack on one of the protocols being reported on. Pointing to the potential attacks in the security considerations sections of the protocol documents would help.

This is from Tim's discuss:

This is a revised discuss.  I am adding a discuss position for IANA, whose
questions have not been answered.

Original discuss text:

In most cases, redundant types have been deprecated.  However, both TABLE_DUMP
and TABLE_DUMP_V2
were included as currently supported types.  Isn't V2 a
superset of the old TABLE_DUMP type?  Is there a
reason both need to be
supported?  At a minimum, I think the document could be clearer regarding when
each of
these types SHOULD be used.  (TABLE_DUMP_V2 MUST be used if there are 4
byte ASN values... is there
a SHOULD when we don't have 4 byte ASN values?)

[Ballot discuss]
This is a revised discuss.  I am adding a discuss position for IANA, whose questions have not been answered.

Original discuss text:

In most cases, redundant types have been deprecated.  However, both TABLE_DUMP and TABLE_DUMP_V2
were included as currently supported types.  Isn't V2 a superset of the old TABLE_DUMP type?  Is there a
reason both need to be supported?  At a minimum, I think the document could be clearer regarding when each of
these types SHOULD be used.  (TABLE_DUMP_V2 MUST be used if there are 4 byte ASN values... is there
a SHOULD when we don't have 4 byte ASN values?)

[Ballot comment]
Some editorial issues:

Section 4 begins with "The MRT format defines five Informational Type messages." but only lists two types.  After
a little sleuthing I discovered the other three types are deprecated.  Perhaps that is worth mentioning in section 4.

In Annex A, some deprecated types (e.g., RPING in section A.2.4) include information about the format.  In other
cases (e.g., IDRP in A.2.3), this was omitted.  Is there a reason for the inconsistency?  (Mostly just curious...)

[Ballot discuss]
In most cases, redundant types have been deprecated.  However, both TABLE_DUMP and TABLE_DUMP_V2
were included as currently supported types.  Isn't V2 a superset of the old TABLE_DUMP type?  Is there a
reason both need to be supported?  At a minimum, I think the document could be clearer regarding when each of
these types SHOULD be used.  (TABLE_DUMP_V2 MUST be used if there are 4 byte ASN values... is there
a SHOULD when we don't have 4 byte ASN values?)

[Ballot discuss]
This is an updated DISCUSS that picks up Robert's comment (#5 is new the others are unchanged).

1) Sec 4 (If the Apps ADs have already said this): Need a normative reference to UTF-8.

2) Sec 5.2: Need a normative reference to IPv4 and IPv6 for their address formats.

3) Sec 5.5: Is there some format for this field?

4) As noted in the Richard Barnes' SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02007.html), some of the information in an MRT object could be considered private, especially given that MRT is commonly used to publish router dumps (e.g., through RouteViews [1]).  For example, BGP neighbors that advertise paths to their peers might not expect these paths to be published in an MRT dump.  There is also a proposed extension to MRT that would add geolocation information about the router and its peers [2].  I would suggest that the document add a brief note that some information contained in MRT dumps might be considered private.  Suggested text based on the above:
"
Some information contained in an MRT data structure might be considered sensitive or private.  For example, a BGP peer that sends a message to an MRT-enabled router might not expect that message to be shared beyond the AS to which it is sent.  The proposed geolocation extension to MRT could reveal the location of an MRT router's peers [I-D.ietf-grow-geomrt].  An organization that intends to use the MRT structure to export routing information beyond the domain where it normally accessible (e.g., publishing MRT dumps for use by researchers) should verify with any peers whose information might be included, and possibly remove sensitive fields.
"

5) The Security Considerations section explore the ramifications of protecting the transport of data in this format (and perhaps even the timing of its availability) to avoid informing an eavesdropper that wishes to mount an attack on one of the protocols being reported on. Pointing to the potential attacks in the security considerations sections of the protocol documents would help.

[Ballot discuss]
This is an updated DISCUSS that picks up Robert's comment (add a #5).

1) Sec 4 (If the Apps ADs have already said this): Need a normative reference to UTF-8.

2) Sec 5.2: Need a normative reference to IPv4 and IPv6 for their address formats.

3) Sec 5.5: Is there some format for this field?

4) As noted in the Richard Barnes' SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02007.html), some of the information in an MRT object could be considered private, especially given that MRT is commonly used to publish router dumps (e.g., through RouteViews [1]).  For example, BGP neighbors that advertise paths to their peers might not expect these paths to be published in an MRT dump.  There is also a proposed extension to MRT that would add geolocation information about the router and its peers [2].  I would suggest that the document add a brief note that some information contained in MRT dumps might be considered private.  Suggested text based on the above:
"
Some information contained in an MRT data structure might be considered sensitive or private.  For example, a BGP peer that sends a message to an MRT-enabled router might not expect that message to be shared beyond the AS to which it is sent.  The proposed geolocation extension to MRT could reveal the location of an MRT router's peers [I-D.ietf-grow-geomrt].  An organization that intends to use the MRT structure to export routing information beyond the domain where it normally accessible (e.g., publishing MRT dumps for use by researchers) should verify with any peers whose information might be included, and possibly remove sensitive fields.
"

5) The Security Considerations section explore the ramifications of protecting the transport of data in this format (and perhaps even the timing of its availability) to avoid informing an eavesdropper that wishes to mount an attack on one of the protocols being reported on. Pointing to the potential attacks in the security considerations sections of the protocol documents would help.

[Ballot comment]
Support Sean's point 4 (re: privacy considerations). I also suggest the Security Considerations section explore the ramifications of protecting the transport of data in this format (and perhaps even the timing of its availability) to avoid informing an eavesdropper that wishes to mount an attack on one of the protocols being reported on. Pointing to the potential attacks in the security considerations sections of the protocol documents would help.

[Ballot discuss]
The DISCUSS and COMMENT is based upon the OPS-DIR review performed by Lionel Morand. I would like to have them answered before I can approve this document.

1. The requested status is "Standard Track" and the wording in the introduction seems not to be appropriate, more relevant for an Informational RFC.

  "This memo serves to document the MRT format as currently implemented
  in publicly available software."

If Standard Track is the right intended status (I believe it is) the language in the introduction should reflect that the document defines a protocol extension for standards track, not just documents existing implementations.

Moreover the original format is extended. Should we have rather something like: "this memo standardize the MRT format as it shall be used..."?

2. The introduction mentions that some type values are deprecated and are given in Appendix for information. But, after that, section by section describing the types and in the IANA section, there is nothing about the deprecated values. Should we mark theses values are reserved? Whatever the decision, something should indicated each time it is required.

[Ballot comment]
"All MRT format messages have a common header which includes a
timestamp, Type, Subtype, and length field.  The header is followed
by a message field.  The MRT common header is illustrated below."

s/includes/consists of/

since includes implies it has other information, or the scope for other information in the future.

also the what you illustrate is the MRT format, not just the common header.

=============

It would have been clearer to have described the microsecond extended common header in it's own right and then call it up in each of the *_ET cases, rather than to have described the IGP _ET modes in terms of the BGP _ET mode.

[Ballot comment]
Just a couple of small things to consider...

---

A couple of places say things like:
  A number of MRT message types have been documented in some references
It would be nice to state the references (informational).

---

Section 5.1
Should Remote IP address and Local IP address fields be explained?

[Ballot comment]
1) Sec 2.4.1: Expand: FSM.

2) Sec 5.1: Isn't it "OSPFv2 Protocol"?  No need to change the type name but (I think) the text referencing 2328 should say OSPFv2.

3) Sec 5.2, para after Figure 3: Should the "may"s and "should" be upper case?

4) Sec 5.2, penultimate paragraph: must or MUST?

5) Sec 5.3: Expand: ASN, NLRI, AS.

6) Sec 5.3, 2nd para: Please reword so that 2119 requirement is not in a "Note".

7) Sec 5.3, 3rd para: r/optional/OPTIONAL

[Ballot discuss]
1) Sec 4 (If the Apps ADs have already said this): Need a normative reference to UTF-8.

2) Sec 5.2: Need a normative reference to IPv4 and IPv6 for their address formats.

3) Sec 5.5: Is there some format for this field?

4) As noted in the Richard Barnes' SECDIR review (http://www.ietf.org/mail-archive/web/secdir/current/msg02007.html), some of the information in an MRT object could be considered private, especially given that MRT is commonly used to publish router dumps (e.g., through RouteViews [1]).  For example, BGP neighbors that advertise paths to their peers might not expect these paths to be published in an MRT dump.  There is also a proposed extension to MRT that would add geolocation information about the router and its peers [2].  I would suggest that the document add a brief note that some information contained in MRT dumps might be considered private.  Suggested text based on the above:
"
Some information contained in an MRT data structure might be considered sensitive or private.  For example, a BGP peer that sends a message to an MRT-enabled router might not expect that message to be shared beyond the AS to which it is sent.  The proposed geolocation extension to MRT could reveal the location of an MRT router's peers [I-D.ietf-grow-geomrt].  An organization that intends to use the MRT structure to export routing information beyond the domain where it normally accessible (e.g., publishing MRT dumps for use by researchers) should verify with any peers whose information might be included, and possibly remove sensitive fields.
"

IANA has questions about this document.

IANA understands that a new registry is to be created for MRT upon
approval of this document.

The new registry will consist of MRT Type Codes and, in some cases,
subcodes for those Type Codes.

For the new registry of Type Codes, IANA understands that the range of
registrations will be the integers 0 through 65535.

0 Reserved
1-64 Allocated (see below)
65 - 511 Available (Assigned by IETF Review)
512 - 2047 Available (Assigned by Specification)
2048 - 64511 Available (Assigned First Come, First Served)
64512 - 65534 Available (Experimental Use)
65535 Reserved

IANA QUESTION: Values 1 through 64 are marked allocated in section 7.1
of the document. However, section 5 only accounts for nine of those
values. IANA notes that other MRT Type Codes are documented in the
Appendix. Should those be added to the registry but marked deprecated?
If not, what should IANA register in the values not covered in this list:

11 OSPF
12 TABLE_DUMP
13 TABLE_DUMP_V2
16 BGP4MP
17 BGP4MP_ET
32 ISIS
33 ISIS_ET
48 OSPFv3
49 OSPFv3_ET

IANA Question: For each of the MRT Type Codes what information should be
registered? The tuple  or something else?

Several of the MRT Type Codes has Subtypes. IANA understands that these
should be registered under the associated MRT Type Code.

Subtype codes are always in the range 0 to 65535. Unless specified
otherwise, Subtype assignmnents to Type Codes 0 - 511 are to be assigned
by IETF Review. Subtype assignments for the remaning Type Codes follow
the assignment rules for the Type Codes to which they belong.

Upon approval of this document, IANA understands the following MRT
Subtype Codes will be defined.

MRT Type Code 11 (ISPF)
0 OSPF_STATE_CHANGE [RFC-to-be]
1 OSPF_LSA_UPDATE [RFC-to-be]
2 - 65535 Unassigned

MRT Type Code 12 (TABLE_DUMP)
0 Unassigned
1 AFI_IPv4 [RFC-to-be]
2 AFI_IPv6 [RFC-to-be]
3 - 65535 Unassigned

MRT Type Code 13 (TABLE_DUMP_V2)
1 PEER_INDEX_TABLE [RFC-to-be]
2 RIB_IPV4_UNICAST [RFC-to-be]
3 RIB_IPV4_MULTICAST [RFC-to-be]
4 RIB_IPV6_UNICAST [RFC-to-be]
5 RIB_IPV6_MULTICAST [RFC-to-be]
6 RIB_GENERIC [RFC-to-be]
7 - 65535 Unassigned

MRT Type Code 16 (BGP4MP)
0 BGP4MP_STATE_CHANGE [RFC-to-be]
1 BGP4MP_MESSAGE [RFC-to-be]
2 Unassigned
3 Unassigned
4 BGP4MP_MESSAGE_AS4 [RFC-to-be]
5 BGP4MP_STATE_CHANGE_AS4 [RFC-to-be]
6 BGP4MP_MESSAGE_LOCAL [RFC-to-be]
7 BGP4MP_MESSAGE_AS4_LOCAL [RFC-to-be]
8 - 65535 Unassigned

IANA QUESTION: Should the state values and the AFI types for these
subtypes be registered?

MRT Type Code 17 (BGP4MP_ET)
0 BGP4MP_STATE_CHANGE [RFC-to-be]
1 BGP4MP_MESSAGE [RFC-to-be]
2 Unassigned
3 Unassigned
4 BGP4MP_MESSAGE_AS4 [RFC-to-be]
5 BGP4MP_STATE_CHANGE_AS4 [RFC-to-be]
6 BGP4MP_MESSAGE_LOCAL [RFC-to-be]
7 BGP4MP_MESSAGE_AS4_LOCAL [RFC-to-be]
8 - 65535 Unassigned

IANA QUESTION: As with MRT Type Code 16, should the state values and the
AFI types for these subtypes be registered?

IANA understands that these tasks represent all the actions required
upon approval of the document.

(1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Peter Schoenmaker, co-chair of the GROW Working Group. 
I have reviewed this document, and i believe the document is ready for
publication.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document has been extensively reviewed both inside the working group
and outside.  There have been a number of existing implementations of MRT
along with new ones writen based on the specification in the document.  A
large number of people have reviewed this document and provided input which
was incorporated in updated revisions.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

Extensive review has been preformed.  No further review is needed.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

I have no concerns related to this document.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is large scale consensus of this document.  No major objections.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No discontent has been expressed on any portion of this document.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

There are no nits in this document.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

This document has been split properly into normative and informative
references.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The document will require new IANA regiesteries.  There are two new
registries required, a Type Codes registry and a subtype codes registry.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no formal languages used in this document.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
    This document describes the MRT format for routing information
    export.  This format was developed in concert with the
            Multi-threaded Routing Toolkit (MRT) from whence the format
            takes it name.  The format can be used to export routing
            protocol messages, state changes, and routing information base
            contents.

          Working Group Summary
    The working group spent a significant amount of time looking
            at and reviewing this document.  Updates where made based on
            working group review, and requests for clarification.  There
            was consensus from the working group at last call.

          Document Quality
    Several existing implements exist for this document.  A new
            implementation was written during the review process of the
            draft.  Specificly Geoff Huston, attempted to write code
            based on the draft, and drove some clarifications, and issues
            based on his work.  The industry currently uses the protocol
            for export of the routing information.  In addition different
            users are using the exported data as input for specific
            applications.

          Personnel
            The document has been reviewed by Peter Schoenmaker (WG
            co-chair.)  Ron Bonica and Dan Romascanu are the ops area
            directors.