Re: [Idr] draft-djsmith-bgp-flowspec-oid-01.txt

[Robert Raszuk <[e-mail]>]

> you gotta love the ref to 5575 which essentially says you have no
> protection, abandon all hope ye who enter

For the record .. this is not what below quote says.

    No new security issues are introduced by relaxing the validation
    procedure for IBGP learned flow specifications. With this proposal,
    the security characteristics of BGP flow specifications remain
    equivalent to the existing security properties of BGP unicast
    routing.  Traffic flow specifications learned from IBGP peers are
    trusted, hence, its not required to validate that the originator of
    an intra-domain traffic flow specification matches the originator of
    the best-match unicast route for the flow destination prefix.
    Conversely, this proposal continues to enforce the validation
    procedure for EBGP learned traffic flow specifications. In this way,
    the security properties of RFC 5575 are maintained such that an EBGP
    peer cannot cause a denial-of-service attack by advertising an
    inter-domain flow specification for a destination prefix that it does
    not provide reachability information for.

Explanation:

The RFC says that for IBGP even with relaxed validation you get what you 
have today .. provided that you know how to protect your AS in the first 
place.

For EBGP the validation is in place and matching last AS as unicast 
route injector with flow spec is sufficient. The DDoS attack to a 
particular destination may have been detected just by your peer and it 
is WRONG to mandate full AS_PATH match.

That would mean that flow-spec filter would need to be injected by the 
target and would consume bandwith of all transit ASes in the AS_PATH. 
This is wrong.

I admit we did not consider RS @ IX when writing section 6.

R.