Sriram,
On Dec 19, 2012, at 8:25 AM, "Sriram, Kotikalapudi"
<[email protected]> wrote:
>>> Whichever prefix (or more specific of it) that the mitigator and the victim
>>> decide to
>>> propagate (via the mitigator) for DDoS mitigation today in BGP, the same
>>> prefix can also
>>> be propagated with BGPSEC (and more securely).
>>
>> I thought we were just talking about _Origin_ Validation, not BGPSEC?
>
> Well, we were talking about both. But we can talk one at a time.
> It is well known that origin_only_validation has limitations in general
> (e.g., spoofed origin, subprefix hijack with spoofed origin, etc.).
> In fact, the DDoS mitigation being discussed here is taking advantage of
> those limitations in the origin_only_validation case.
> BGPSEC overcomes the limitations of origin_only_validation, and works
> quite cleanly (IMHO) in this DDoS mitigation scenario for the benefit of
> the victim and the mitigator.
I'm not sure I'd agree with your assessment, but see below for why.
>>> If “all providers filter on announcements > /24” as you say,
>>> then that is a constraint for the DDoS mitigation method under discussion
>>> regardless of whether it is in BGP or BGPSEC.
>>
>> Not true. There are a variety of techniques available today, which will
>> fail with Origin Validation. By way of a couple of examples, here they are.
>> First, "Proxy AS" originates same /24 as "Victim AS".
>> 1) "Victim AS" then withdraws their /24 and falls back on an existing,
>> covering aggregate, e.g.: /23, /20, etc. for delivery of the scrubbed
>> traffic.
>> 2) "Victim AS" performs AS_PATH prepending of their /24 to make it less
>> preferred compared to the new, shorter AS_PATH length "Proxy AS" origination.
>> 3) "Victim AS" uses their SP's BGP "Traffic Engineering" Communities to
>> signal to their Service Provider(s) to lower LOCAL_PREF of the Victim's /24,
>> inside their SP(s) AS, compared to the /24 being announced from "Proxy AS".
>>
>> It's all about intent ...
>
> I read what you described above quite carefully twice.
> But it is not clear to me how origin_only_validation fails or interferes
> in any of the methods you outlined above.
> I am sure you recognize by now that with origin_only_validation in place,
> in the proposed solution, the mitigator needs to spoof the victim’s origin
> in order to pass ROA validation.
There are still a few problems with your proposal:
1) Spoofing the Origin ASN means you will always have a longer AS_PATH length
("Spoofed Origin ASN + Proxy AS") vs. just originating the IP prefix from the
"Proxy AS". Yes, you can _try_ to workaround that using some of the 'tricks' I
outlined above, but in thinking about this more I'm not sure all of those
techniques I mentioned could be used. In the proposals for Origin Validation
(only), it's suggested that SP's will either:
a) Drop IP prefixes with Invalid Origin (Proxy AS) altogether -- maybe not
now, but that's the _goal_, eventually, right? This would obviously outright
ban "Proxy AS" from originating the IP prefix from that AS for the purposes of
DDoS attack mitigation or other reasons.
b) Lower LOCAL_PREF of "Invalid" Origin vs. Valid Origin (per,
draft-ietf-sidr-origin-ops) ... perhaps for the foreseeable future. So, in
this case, even AS_PATH prepending by the "Victim AS" would not be effective,
because the higher LOCAL_PREF of the Valid Origin/ROA of "Victim AS" will
override the lower LOCAL_PREF of an Invalid Origin/ROA of the "Proxy AS".
... Does the above make it more clear how origin_only validation fails or
interferes with all of the methods I've outlined above?
2) I'm sure you realize that there may not be HW, (routers), available to
perform spoofing of the Origin AS you propose. For example, in the case where
capacity to a customer's site in undersized, it's possible for me to [quickly]
extend a X-connect from my PE router to their L2 switch, (or plug their
servers/switches into my L2 switches connected to my PE router). In that case,
my PE router has one, and only one, global ASN configured on it. I have no
choice *but* to originate that prefix from my ASN, (the "Proxy ASN" if you
will).
3) Since you seem to want to venture into BGPSEC, I'm unclear how you're
proposing to -- again, in an emergency -- get BGPSEC router (or, AS?) keys to
the "Proxy AS" to allow forward-signing of "Spoofed Origin AS -> Proxy AS".
Given the victim is under DDoS attack, transmission of private (?) signing keys
and uploading them into the 3rd-party DDoS mitigators routers to allow the
spoofed Origin AS to forward sign BGP announcements seems, umm, a bit hazardous
(and time-consuming)? Particularly in the case where the Victim AS was using a
per-AS signing key, not a per-router+per-AS signing key. That's going to open
up the Victim AS to a potentially wider attack surface for the duration of
having the DDoS mitigation service spoof the Origin AS, behind their "Transit
AS", and/or the period of time for the Victim AS to publish and roll-over to
new BGPSEC per-AS or per-router-per-AS signing keys, no?
> (Again, if we advance to path validation, then the proposed solution in BGPSEC
> does not require the origin spoofing etc. ... we have already gone over
> that.)
I'm not following your logic here.
-shane
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
