Subject: [secdir] Secdir review of draft-ietf-idr-flow-spec-03.txt

From: Charlie Kaufman <[email-masked]>
Date: Fri, 16 Jan 2009 14:32:48 -0800

I am reviewing this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum.

This document specifies an extension to BGP to allow more granular filtering information for discriminating packet flows to be distributed between Autonomous Systems. The stated goal is to enable better protection from DDoS attacks by pushing firewall style filtering upstream towards the initiators of the DDoS traffic (though one could imagine other uses). So if a particular destination is being attacked by enormous quantities of traffic from many sources but towards a particular address/port pair, upstream routers could be asked to discard all traffic targeting that address/port pair. The security of the extended protocol leverages the security of BGP itself (such as it is), and it seems likely that any attacker who could exploit this protocol to selectively block traffic would be able (even without this extension) to block the same traffic - albeit in a less granular fashion).

There are some issues that might have been discussed in the security considerations section but weren't:

1)       There is no specification in this document as to whether the origin of the information in the extensions is manual or automated, and I don't know whether this is likely to appear in a separate document. One could anticipate operational security problems if changes were not carefully managed. For example, if the changes were automatically generated from an overwhelmed server, the rate at which the flow manipulation data could overwhelm BGPs ability to distribute it. I don't know whether BGP has built in lock-down timers to prevent oscillation in networks or what the effects might be of having BGP information in some ASs be several versions behind the BGP information in others. The size of the BGP information, which previously was administratively controlled, might also grow without bound with unknown effects.

2)       Using BGP to distribute information in response to attacks is controversial (as discussed in the introduction of the document). An important factor in its appropriateness is whether BGP can distribute the information throughout the network quickly enough to be useful given the duration of the attacks. Some discussion of this issue (in particular estimated times) would be helpful.

3)       Enabling firewall-like capabilities in routers without centralized management could make certain failures harder to diagnose. For example, with the extensions it is possible to allow TCP packets to pass between a pair of addresses but not ICMP packets. It would also be possible to permit packets smaller than 900 or greater than 1000 bytes to pass between a pair of addresses, but not packets whose length is in the range 900-1000. The Internet has become sufficiently aware of firewalls that such behavior is less likely to be confusing than it was a few years ago, and there are no new capabilities introduced by these extensions - just an increased likelihood that such capabilities will be used.

4)       These extensions allow filtering based on TCP/UDP ports and other detailed information in ordinary packets, but not in ESP or AH protected packets even when the packet contents are unencrypted.

5)       Section 5 last paragraph: There is a statement that the neighboring AS must be the left-most field in the AS_PATH attribute for security reasons. What are the security reasons, and does this statement apply only to versions of BGP processing this extension or to all versions.

Some other issues that are not specifically security related:

1)       There appears to be no explicit support for IPv6. It is not one of the selection criteria, and address masks are specified with a prefix bit length and a value. Since a prefix bit length and value could mean radically different things in the IPv4 and IPv6 address spaces, this should be disambiguated. (Or it's possible that separate instances of BGP exist for IPv4 and IPv6, in which case there is no problem but it should probably mention that in the spec when discussing address masks).

2)       There were a large number of acronyms that were not defined (at least not on first use). These are probably familiar to people working on BGP, but it would be helpful to specify the RFCs in which acronym expansions/definitions could be found. Among them: NLRI, RIBs, Loc-RIB, AS, VRF, and PE.

3)       Section 5 paragraph 2 references section 9.1.2. Since this document has no section 9.1.2, I suspect it means section 9.1.2 of some other document. It should say which one.

4)       Section 7 5th paragraph contains a number of grammatical errors (apparently based on editing a singular into a plural at the last minute.

5)       Section 10 paragraph 3 requests that IANA allocate three constants from the "BGP Extended Communities Type - Experimental Use" registry. Is this document targeting experimental status? If not, is that the right registry from which to get values?

6)       Section 10 last paragraph says that future assignments to a registry are to be made either through "Standards Action", "the Early IANA Allocation process", or the "First Come First Served" policy. Doesn't each registry (or at least each section of each registry) have to specify which of those procedures is to be followed?

_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 16 Jan 2009 15:13:18 -0800

Charlie,
I'll attempt to clarify some questions inline.

On Jan 16, 2009, at 2:32 PM, Charlie Kaufman wrote:

> I am reviewing this document as part of the security directorate's  
> ongoing effort to review all IETF documents being processed by the  
> IESG.  These comments were written primarily for the benefit of the  
> security area directors.  Document editors and WG chairs should  
> treat these comments just like any other last call comments. Feel  
> free to forward to any appropriate forum.
>
> This document specifies an extension to BGP to allow more granular  
> filtering information for discriminating packet flows to be  
> distributed between Autonomous Systems. The stated goal is to enable  
> better protection from DDoS attacks by pushing firewall style  
> filtering upstream towards the initiators of the DDoS traffic  
> (though one could imagine other uses). So if a particular  
> destination is being attacked by enormous quantities of traffic from  
> many sources but towards a particular address/port pair, upstream  
> routers could be asked to discard all traffic targeting that address/ 
> port pair. The security of the extended protocol leverages the  
> security of BGP itself (such as it is), and it seems likely that any  
> attacker who could exploit this protocol to selectively block  
> traffic would be able (even without this extension) to block the  
> same traffic – albeit in a less granular fashion).
>
> There are some issues that might have been discussed in the security  
> considerations section but weren’t:
>
> 1)       There is no specification in this document as to whether  
> the origin of the information in the extensions is manual or  
> automated, and I don’t know whether this is likely to appear in a  
> separate document.

We have seen deployments using automated detection systems (e.g.  
Arbor) and manual configuration.

> One could anticipate operational security problems if changes were  
> not carefully managed. For example, if the changes were  
> automatically generated from an overwhelmed server, the rate at  
> which the flow manipulation data could overwhelm BGPs ability to  
> distribute it.

I believe this issue is no different from the origination of unicast  
routes. Depending on the deployment, these can either be manually  
configured or generated by provisioning systems / scripts.

Would it suffice if the document spells out that when automated  
systems are used care should be taken to their correctness and rate of  
advertisement ?

> I don’t know whether BGP has built in lock-down timers to prevent  
> oscillation in networks or what the effects might be of having BGP  
> information in some ASs be several versions behind the BGP  
> information in others. The size of the BGP information, which  
> previously was administratively controlled, might also grow without  
> bound with unknown effects.

BGP has mechanisms to control these. e.g. it is common to limit the  
number of prefixes that can be received from a particular peer.

> 2)       Using BGP to distribute information in response to attacks  
> is controversial (as discussed in the introduction of the document).  
> An important factor in its appropriateness is whether BGP can  
> distribute the information throughout the network quickly enough to  
> be useful given the duration of the attacks. Some discussion of this  
> issue (in particular estimated times) would be helpful.

This mechanism is appropriate to mitigate attacks that last dozens of  
minutes or hours. It is not appropriate to address attacks that last  
less than a minute.

BGP propagation time is irrelevant in the equation. The detection time  
is the bottleneck, specially when manual methods are considered. Today  
that is the most common detection method: alarm raised in management  
console, human intervention, phone call, manual config.

> 3)       Enabling firewall-like capabilities in routers without  
> centralized management could make certain failures harder to  
> diagnose. For example, with the extensions it is possible to allow  
> TCP packets to pass between a pair of addresses but not ICMP  
> packets. It would also be possible to permit packets smaller than  
> 900 or greater than 1000 bytes to pass between a pair of addresses,  
> but not packets whose length is in the range 900-1000. The Internet  
> has become sufficiently aware of firewalls that such behavior is  
> less likely to be confusing than it was a few years ago, and there  
> are no new capabilities introduced by these extensions – just an  
> increased likelihood that such capabilities will be used.

That is a good point. You would like this reflected in the security  
considerations ?

> 4)       These extensions allow filtering based on TCP/UDP ports and  
> other detailed information in ordinary packets, but not in ESP or AH  
> protected packets even when the packet contents are unencrypted.

Correct. That is a typical limitation in filtering hardware.

> 5)       Section 5 last paragraph: There is a statement that the  
> neighboring AS must be the left-most field in the AS_PATH attribute  
> for security reasons. What are the security reasons, and does this  
> statement apply only to versions of BGP processing this extension or  
> to all versions.

Since the verification procedure uses the neighbor AS in the AS_PATH  
attribute [ b) no more-specific rules from a different AS], it becomes  
necessary to enforce that the neighbor as is correct and as not been  
faked. i.e. it must match the configuration. This rule is required  
when this extension is in use.

> 1)       There appears to be no explicit support for IPv6. It is not  
> one of the selection criteria, and address masks are specified with  
> a prefix bit length and a value. Since a prefix bit length and value  
> could mean radically different things in the IPv4 and IPv6 address  
> spaces, this should be disambiguated. (Or it’s possible that  
> separate instances of BGP exist for IPv4 and IPv6, in which case  
> there is no problem but it should probably mention that in the spec  
> when discussing address masks).

IPv6 would be a different AFI, SAFI and go into a different BGP  
database.

> 2)       There were a large number of acronyms that were not defined  
> (at least not on first use). These are probably familiar to people  
> working on BGP, but it would be helpful to specify the RFCs in which  
> acronym expansions/definitions could be found. Among them: NLRI,  
> RIBs, Loc-RIB, AS, VRF, and PE.

Can easily be accommodated.

> 3)       Section 5 paragraph 2 references section 9.1.2. Since this  
> document has no section 9.1.2, I suspect it means section 9.1.2 of  
> some other document. It should say which one.

The base BGP spec (RFC 4271).

> 4)       Section 7 5th paragraph contains a number of grammatical  
> errors (apparently based on editing a singular into a plural at the  
> last minute.
> 5)       Section 10 paragraph 3 requests that IANA allocate three  
> constants from the “BGP Extended Communities Type – Experimental  
> Use” registry. Is this document targeting experimental status? If  
> not, is that the right registry from which to get values?

These are the values used in current deployments. At this point given  
that the deployments are very limited in number it would be reasonable  
to consider it experimental.

> 6)       Section 10 last paragraph says that future assignments to a  
> registry are to be made either through “Standards Action”, “the  
> Early IANA Allocation process”, or the “First Come First Served”  
> policy. Doesn’t each registry (or at least each section of each  
> registry) have to specify which of those procedures is to be followed?

That is a good point. I'd be tempted to say that we should just follow  
"first come first served". Would that be acceptable ?

---

From: Barry Greene <[email-masked]>
Date: Sat, 17 Jan 2009 06:35:49 -0800

> > automated, and I don't know whether this is likely to appear in a 
> > separate document.
> 

To be more explicit, the triggering is controlled by a separate
component - be it manual or by a "controller" (systems like Arbor
Network's Peekflow or NARUS's equivalent). Right now, operators do not
want "automatic" triggering of FlowSpec, dRTBH (Destination base Remote
Triggered Black Hole), or sRTBH (Source based Remote Triggered Black
Hole).

What would be beneficial is to have a architecture document plugging in
the following:

-> RFC 3882 "Configuring BGP to Block Denial-of-Service Attacks" (dRTBH)
-> draft-ietf-idr-flow-spec.txt 
-> draft-kumari-blackhole-urpf-02.txt (sRTBH)
-> Trusted Information Distribution Protocol (TIDP) (when it get
submitted as an ID)

OPSEC would be the logical place for this work.
 
> > One could anticipate operational security problems if 
> changes were not 
> > carefully managed. For example, if the changes were automatically 
> > generated from an overwhelmed server, the rate at which the flow 
> > manipulation data could overwhelm BGPs ability to distribute it.
> 
> I believe this issue is no different from the origination of 
> unicast routes. Depending on the deployment, these can either 
> be manually configured or generated by provisioning systems / scripts.
> 
> Would it suffice if the document spells out that when 
> automated systems are used care should be taken to their 
> correctness and rate of advertisement ?

It might be spelled out better in the document. The three major areas of
action in the architecture - the controller, the distribution of the
policy (FlowSpec), and the behavior of the device which when
encountering policy collisions or policy overloads are three separate
areas. The later is a vendor specific issue - given that it is related
to how the hardware is designed.

> > I don't know whether BGP has built in lock-down timers to prevent 
> information 
> > in others. The size of the BGP information, which previously was 
> > administratively controlled, might also grow without bound with 
> > unknown effects.
> 
> BGP has mechanisms to control these. e.g. it is common to 
> limit the number of prefixes that can be received from a 
> particular peer.
> 
> > distribute the information throughout the network quickly 
> enough to be 
> > useful given the duration of the attacks. Some discussion of this 
> This mechanism is appropriate to mitigate attacks that last 
> dozens of minutes or hours. It is not appropriate to address 
> attacks that last less than a minute.
> 
> BGP propagation time is irrelevant in the equation. The 
> detection time is the bottleneck, specially when manual 
> methods are considered. Today that is the most common 
> detection method: alarm raised in management console, human 
> intervention, phone call, manual config.

Some might say it using BGP is "controversial," but BGP triggered
mitigation _IS_ the #1 tool to mitigate DDOS attacks, whack down
BOTNETs, and mitigate the badness on the Net.

The selection of BGP was done specifically for its predictability and
speed (as Pedro mentioned above). 

> > centralized management could make certain failures harder 
> to diagnose. 
> > For example, with the extensions it is possible to allow 
> TCP packets 
> > to pass between a pair of addresses but not ICMP packets. It would 
> > also be possible to permit packets smaller than 900 or greater than 
> > 1000 bytes to pass between a pair of addresses, but not 
> packets whose 
> > length is in the range 900-1000. The Internet has become 
> sufficiently 
> > aware of firewalls that such behavior is less likely to be 
> confusing 
> > than it was a few years ago, and there are no new capabilities 
> > introduced by these extensions - just an increased likelihood that 
> > such capabilities will be used.
> 
> That is a good point. You would like this reflected in the 
> security considerations ?

It is worth looking through the draft to see how we expressed this, but
BGP triggered mechanisms (dRTBH, sRTBH, & FlowSpec) are marco filtering
done for initial mitigation. It should not be confused with firewalls or
firewall management.

> Correct. That is a typical limitation in filtering hardware.

Or more explicit, FlowSpec is designed specific for the Router/Switch
orientation of filtering on the box. If you need more granular filtering
you would use BGP Shunts (where FlowSpec can be used), MPLS Shunts, or
TIDP. Today Shunting to a Sink Hole or a DDOS mitigation/DPI device is
used for granular filtering.
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 18 Jan 2009 11:28:58 -0800

Hi Charlie,

Based on your comments and replies from authors I have updated the draft 
and proposed changes and clarifications are included in the -04 version.

http://www.ietf.org/proceedings/staging/draft-ietf-idr-flow-spec-04.txt

If there are any other questions or additional comments I will be happy 
to incorporate them and issue -05 version of the document.

Many thx for your excellent review,
Robert Raszuk

> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments. Feel free to 
> forward to any appropriate forum.
> 
>  
> 
> filtering information for discriminating packet flows to be distributed 
> between Autonomous Systems. The stated goal is to enable better 
> protection from DDoS attacks by pushing firewall style filtering 
> upstream towards the initiators of the DDoS traffic (though one could 
> imagine other uses). So if a particular destination is being attacked by 
> enormous quantities of traffic from many sources but towards a 
> particular address/port pair, upstream routers could be asked to discard 
> all traffic targeting that address/port pair. The security of the 
> extended protocol leverages the security of BGP itself (such as it is), 
> and it seems likely that any attacker who could exploit this protocol to 
> selectively block traffic would be able (even without this extension) to 
> block the same traffic – albeit in a less granular fashion).
> 
>  
> 
> 1)       There is no specification in this document as to whether the 
> origin of the information in the extensions is manual or automated, and 
> I don’t know whether this is likely to appear in a separate document. 
> One could anticipate operational security problems if changes were not 
> manipulation data could overwhelm BGPs ability to distribute it. I don’t 
> know whether BGP has built in lock-down timers to prevent oscillation in 
> networks or what the effects might be of having BGP information in some 
> ASs be several versions behind the BGP information in others. The size 
> of the BGP information, which previously was administratively 
> controlled, might also grow without bound with unknown effects.
> 
> 2)       Using BGP to distribute information in response to attacks is 
> controversial (as discussed in the introduction of the document). An 
> important factor in its appropriateness is whether BGP can distribute 
> the information throughout the network quickly enough to be useful given 
> the duration of the attacks. Some discussion of this issue (in 
> particular estimated times) would be helpful.
> 
> centralized management could make certain failures harder to diagnose. 
> For example, with the extensions it is possible to allow TCP packets to 
> pass between a pair of addresses but not ICMP packets. It would also be 
> possible to permit packets smaller than 900 or greater than 1000 bytes 
> to pass between a pair of addresses, but not packets whose length is in 
> the range 900-1000. The Internet has become sufficiently aware of 
> firewalls that such behavior is less likely to be confusing than it was 
> a few years ago, and there are no new capabilities introduced by these 
> extensions – just an increased likelihood that such capabilities will be 
> used.
> 
> neighboring AS must be the left-most field in the AS_PATH attribute for 
> security reasons. What are the security reasons, and does this statement 
> apply only to versions of BGP processing this extension or to all versions.
> 
>  
> 
> *1)       **There appears to be no explicit support for IPv6. It is not 
> one of the selection criteria, and address masks are specified with a 
> prefix bit length and a value. Since a prefix bit length and value could 
> mean radically different things in the IPv4 and IPv6 address spaces, 
> this should be disambiguated. (Or it’s possible that separate instances 
> of BGP exist for IPv4 and IPv6, in which case there is no problem but it 
> should probably mention that in the spec when discussing address masks).*
> 
> 2)       There were a large number of acronyms that were not defined (at 
> least not on first use). These are probably familiar to people working 
> on BGP, but it would be helpful to specify the RFCs in which acronym 
> expansions/definitions could be found. Among them: NLRI, RIBs, Loc-RIB, 
> AS, VRF, and PE.
> 
> document has no section 9.1.2, I suspect it means section 9.1.2 of some 
> other document. It should say which one.
> 
> 4)       Section 7 5^th paragraph contains a number of grammatical 
> errors (apparently based on editing a singular into a plural at the last 
> minute.
> 
> constants from the “BGP Extended Communities Type – Experimental Use” 
> registry. Is this document targeting experimental status? If not, is 
> that the right registry from which to get values?
> 
> registry are to be made either through “Standards Action”, “the Early 
> IANA Allocation process”, or the “First Come First Served” policy. 
> Doesn’t each registry (or at least each section of each registry) have 
> to specify which of those procedures is to be followed?
> 
>  
> 
>  
>

---

From: Danny McPherson <[email-masked]>
Date: Mon, 19 Jan 2009 10:36:23 -0700

On Jan 18, 2009, at 12:28 PM, Robert Raszuk wrote:

> Hi Charlie,
>
> Based on your comments and replies from authors I have updated the  
> draft and proposed changes and clarifications are included in the  
> -04 version.
>
> If there are any other questions or additional comments I will be  
> happy to incorporate them and issue -05 version of the document.

I would note that these changes, the IANA recommendations
for the registry, and the fact that IPR disclosure occurred
after WG last call all suggest that another WG LC is likely
in order here.

-danny