Last Call: draft-ietf-idr-flow-spec (Dissemination of flow specification rules) to Proposed Standard

The IESG has received a request from the Inter-Domain Routing WG (idr) 
to consider the following document:

- 'Dissemination of flow specification rules '
   <draft-ietf-idr-flow-spec-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2009-01-20. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16385&rfc_flag=0

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

I-D Action:draft-ietf-idr-rfc3392bis-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Capabilities Advertisement with BGP-4
	Author(s)       : J. Scudder, R. Chandra
	Filename        : draft-ietf-idr-rfc3392bis-04.txt
	Pages           : 6
	Date            : 2009-01-06

This document defines an Optional Parameter, called Capabilities,
that is expected to facilitate the introduction of new capabilities
in the Border Gateway Protocol (BGP) by providing graceful capability
advertisement without requiring that BGP peering be terminated.  This
document obsoletes RFC 3392.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3392bis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Idr mailing list
Idr <at> ietf.org

registry for BGP optional parameters

Dave,

IDR WG would like to ask IANA to create and maintain a registry for
OPEN message optional parameters called "BGP OPEN Optional Parameter
Type". Optional parameters are identified by the Parameter Type,
which is a one-octet unsigned integer. Values are to be allocated
according to the "IETF Consensus" policy as defined in [RFC5226].

The registry should be populated with the two Parameter Type codes 
that are currently defined:

   o  Parameter Type 1: Authentication (deprecated).

   o  Parameter Type 2: Capabilities ([RFC3392])

Yakov.
------- Forwarded Message

Date:    Wed, 24 Dec 2008 13:14:54 -0800
From:    Yakov Rekhter <yakov <at> juniper.net>
To:      idr <at> ietf.org
Subject: [Idr] registry for BGP optional parameters

Folks,

This is to start the IDR WG Last Call on the following proposal
by John Scudder:

   The base BGP specification [RFC4271] specifies in Section 4.2 a
   mechanism to include optional parameters with the OPEN message.

I-D Action:draft-ietf-idr-rfc3392bis-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Capabilities Advertisement with BGP-4
	Author(s)       : J. Scudder, R. Chandra
	Filename        : draft-ietf-idr-rfc3392bis-05.txt
	Pages           : 7
	Date            : 2009-01-07

This document defines an Optional Parameter, called Capabilities,
that is expected to facilitate the introduction of new capabilities
in the Border Gateway Protocol (BGP) by providing graceful capability
advertisement without requiring that BGP peering be terminated.  This
document obsoletes RFC 3392.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3392bis-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Idr mailing list
Idr <at> ietf.org

Re: I-D Action:draft-ietf-idr-rfc3392bis-05.txt

FYI versions -04 and -05 address feedback received during IESG  
review.  Summary of changes between -03 and -05:

- Added "obsoletes" header.
- Added some additional descriptive text to the Introduction.
- Changed SHOULD to MUST in the case of sending an Unsupported  
Capability NOTIFICATION.
- Changed SHOULD to MUST in the case of ignoring a capability which  
the speaker doesn't recognize.
- Noted that a speaker MUST be prepared to accept multiple instances  
of a capability.  (This was already implicit.)
- Updated acks and change log.

The s/SHOULD/MUST/ changes are nominally normative changes, but ought  
to be non-controversial.

--John

On Jan 7, 2009, at 4:00 PM, <Internet-Drafts <at> ietf.org> <Internet-Drafts <at> ietf.org 
 > wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Inter-Domain Routing Working Group  
> of the IETF.
>
>
> 	Title           : Capabilities Advertisement with BGP-4
> 	Author(s)       : J. Scudder, R. Chandra
> 	Filename        : draft-ietf-idr-rfc3392bis-05.txt

Protocol Action: 'Capabilities Advertisement with BGP-4' to Draft Standard

The IESG has approved the following document:

- 'Capabilities Advertisement with BGP-4 '
   <draft-ietf-idr-rfc3392bis-05.txt> as a Draft Standard

This document is the product of the Inter-Domain Routing Working Group. 

The IESG contact persons are David Ward and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc3392bis-05.txt

Technical Summary

   This document defines an Optional Parameter, called Capabilities,
   that is expected to facilitate the introduction of new capabilities
   in the Border Gateway Protocol (BGP) by providing graceful capability
   advertisement without requiring that BGP peering be terminated.  This
   document obsoletes RFC 3392.

Working Group Summary

   There were no objections to this document within the IDR WG during
the IDR WG Last Call.

Document Quality

  There are multiple, interoperable implementations of this technology.

Personnel

Operational Recommendations on Handling Invalid AS4_PATH Attributes

As discussed on the IETF IDR list last month, there are concerns relating to the
treatment of AS_CONFED_SET/SEQUENCE in AS4_PATH as described in RFC4893 [0].
Since the last post to that thread the situation has been made more urgent with
the release of Cisco IOS 12.0(32)S12, which responds to malformed AS4_PATH
attributes by sending a NOTIFICATION to the neighbour, and tearing down the BGP
adjacency. This behaviour seems to be required by RFC4721 section 6.3, as there
is no alternative error handling defined in RFC4893. As posted last Friday [1],
and discussed on the IDR list, this strict implementation introduces a new
attack vector by which a BGP session can be torn down due to a an attribute
populated by a distant BGP neighbour. These malformed attributes have already
been seen in the wild as a result of a error in Juniper's implementation of
RFC4893. 

Following discussions with a number of operators, we have attempted to generate
some recommendations relating to the behaviour that would be operationally most
useful when treating the invalid data in the AS4_PATH optional transitive
attribute.

There are two cases to consider when an invalid AS4_PATH is received:
   (1) A path to the prefix is not already known from that neighbour. 
   (2) A path to the prefix has already been learnt from that neighbour; 

In case (1) we recommend that the BGP speaker should discard the UPDATE and log
the fact. The log entry should include the received AS_PATH and
AS4_PATH to aid in debugging.

In case (2) we recommend that the BGP speaker should treat the UPDATE as a
withdrawal of existing path to the prefix. As per case (1) a log entry should be
raised to indicate that this has occurred.

Re: Operational Recommendations on Handling Invalid AS4_PATH Attributes

Rob Shakir <rjs <at> eng.gxn.net> wrote:
> 
> ... This behaviour seems to be required by RFC4721 section 6.3, as there
> is no alternative error handling defined in RFC4893.
>...
> Following discussions with a number of operators, we have attempted to
> generate some recommendations relating to the behaviour that would be
> operationally most useful when treating the invalid data in the
> AS4_PATH optional transitive attribute.

   I have no desire to criticize, but I think it may be helpful to step
back for a moment.

   The _useful_ information in AS4_PATH is the 4-byte ASNs where OLD
speakers must place AS_TRANS. We might consider whether that information
is useful in cases where RFC4893's algorithm produces invalid data. (I
frankly doubt we have found all possible cases yet.)

   I can imagine a treatment where we abandon the 4893 algorithm and
simply substitute 4-byte ASNs for AS_TRANS in the AS_PATH received from
an OLD speaker. This would preserve loop-detection for 4-byte ASNs
while matching other characteristics of the NLRI received from our OLD
peer.

   Obviously this would be better than tearing down the session with our
OLD peer; the question is, would it be better than discarding the new
NLRI?

--
John Leslie <john <at> jlc.net>

I-D Action:draft-ietf-idr-flow-spec-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Dissemination of flow specification rules
	Author(s)       : P. Roque Marques, et al.
	Filename        : draft-ietf-idr-flow-spec-04.txt
	Pages           : 21
	Date            : 2009-01-18

This document defines a new BGP NLRI encoding format that can be used
to distribute traffic flow specifications.  This allows the routing
system to propagate information regarding more-specific components of
the traffic aggregate defined by an IP destination prefix.

Additionally it defines two applications of that encoding format.
One that can be used to automate inter-domain coordination of traffic
filtering, such as what is required in order to mitigate
(distributed) denial of service attacks.  And a second application to
traffic filtering in the context of a BGP/MPLS VPN service.

The information is carried via the Border Gateway Protocol (BGP),
thereby reusing protocol algorithms, operational experience and
administrative processes such as inter-provider peering agreements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

[Fwd: I-D Action:draft-chen-rfc4893bis-00.txt]

Hi, folks:

The changes from RFC 4893 are summarized in the Appendix of the draft:

      This document clarifies the handling of the confederation path
      segments in the AS4_PATH attribute, and also specifies the error
      handling for the new attributes.

The following are the specific additions:

-----------------------
3. Protocol Extensions

 A NEW BGP speaker SHOULD NOT send these path segment
 types in the AS4_PATH attribute of an UPDATE message.  A NEW BGP
 speaker that receives these path segment types in the AS4_PATH
 attribute of an UPDATE message MUST discard these path segments,
 adjust the relevant attribute fields accordingly, and continue
 processing the UPDATE message.

6. Error Handling

 When a NEW BGP speaker encounters an error (other than the invalid
 confederation path segment types described previously) in parsing the
 AS4_PATH attribute or the AS4_AGGREGATOR attribute of an UPDATE
 message, the speaker MUST discard the attribute in error, and
 continue processing the UPDATE message. The error SHOULD be logged
 locally for analysis.

9. Security Considerations