On Dec 19, 2012, at 2:12 PM, "Sriram, Kotikalapudi"
<[email protected]> wrote:
[--snip--]
FWIW, I disagree with your assertions, but am cutting to the chase, because I
think you're still failing to understand why/when it's not possible to "spoof"
the Victim's AS.
>> 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).
>>
>
> Is this that much different from AS prepending? Instead of inserting multiple
> times the PE router's ASN (in the prepending case), it inserts once the
> DDoS-mitigation customer's ASN in the path. Alternatively, the victim can
> set up a BGP session to the mitigator and inject the route
> (no spoofing by proxy AS in that case).
> But then I am not a developer/implementer ;)
There is no PE <-> CE eBGP session where one can originate the IP Prefix from
the "Victim AS". There is just this:
ISP
Proxy-AS Victim IP prefix
AS1
+------+ +-------------------------------------+
| PE-1 |======| Victim's L2 switches and/or servers |
+------+ +-------------------------------------+
^
|
+---- This is not a CE router
On the router PE-1, in the ISP AS (AS1), I am originating a BGP announcement
for a _directly_connected_ prefix, where the victim's server/network/service is
located. I am not aware of a capability in any implementation that I'm
familiar with where I can originate that directly connected IP prefix for the
Victim's network and have it appear to be from the Victim's Original AS. When
I originate an IP prefix on PE-1, the Origin-AS of that IP prefix is AS1, the
"Proxy AS", not the "Victim's AS". Then again, perhaps I have not looked hard
enough at existing implementations ...
Quite frankly, *not* having the capability in router implementations to
Originate an IP prefix with any random Origin_AS, (e.g.: PE-1), is possibly one
of the more effective deterrents /against/ mis-originating an IP prefix from
the 'intended'/correct Origin AS -- ooooh, there's that word "intent" again.
>> 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?
>>
>
> The solution that Oliver and I suggested does not have any of the
> complications
> that you mention above:
> http://www.ietf.org/mail-archive/web/sidr/current/msg05501.html
> http://www.ietf.org/mail-archive/web/sidr/current/msg05504.html
> The victim AS does not need to transfer any router keys to the proxy AS.
> Instead the victim AS provides a signed update (with pCount=0) to the
> proxy AS (by creating a BGPSEC peering session or by other suitable means).
Awesome. So, now we've got a recommendation to:
a) Spoof the Victim's Origin AS; and,
b) Use pCount = 0 to avoid validating the AS_PATH signatures
I'm failing to see what the group is trying to accomplish here if these are the
recommendations. One has to question what value there is in deploying Origin
Validation & BGPSEC if the answer when it can't accommodate a operationally
viable scenarios is to effectively "turn it off".
-shane
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
