>
>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:
This has been said before but worth a repeat --
Talking about the spoofed origin ASN solution,
the concern about path length increase by one hop really
goes away because, as Danny has also pointed out, the mitigator wants to be
rather surgical and hence announces a more specific (longer length) prefix
in most cases. Thus, the mitigator is drawing towards itself the traffic
that is DDoS'ing the victim's server but minimizes drawing traffic destined
to other unaffected parts of the victim's address space.
Due to the spoofed origin ASN, the proxy AS's BGP update is always Valid
(in terms of the origin-only-validation outcome).
I feel that none of the workaround tricks you mention are necessary
considering that the BGP announcement from the proxy AS is for
a more specific prefix (most of the time) and it is always Valid
> 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.
This concern goes away per explanation provided above.
> 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".
This concern also goes away per explanation provided above.
>... Does the above make it more clear how origin_only validation fails or
>interferes with all of the methods I've outlined above?
As I have explained above, we can eliminate the possibility of failure or
interference
by two means: (1) Proxy AS spoofs origin AS; (2) Proxy AS announces
a more specific prefix (in most cases of DDoS mitigation).
>
>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 ;)
>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).
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
