>
> 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.
>
Sorry, I tried my best to try to understand your point but well …
But thanks very much indeed for your patience.
I guess this particular point ( i.e. why/when it's not possible to "spoof" the
Victim's AS)
needs some paper and pencil (or white board) discussion.
Hopefully, we can do that when we meet in person (at NANOG in Feb?).
>>
--snip--
>
> 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 ...
Thanks for the nice figure and the explanation. But I think there is a way.
I assume the ISP (Proxy AS) is the DDoS mitigator.
Is the L2 connection (1) an existing business relationship between the two
parties, or
(2) is being established in emergency after the victim came under attack and
made a panic phone call to the DDoS mitigator (Proxy AS1)?
If it is case (1), then a ROA can be created well in advance (of any emergency)
permitting
the victim’s prefix to be announced from AS1. Right?
If it is case (2), then for what purpose is the L2 connection being set up?
It appears to me that it is for the Proxy AS1 to channel the scrubbed traffic
back to the victim’s network. True?
So the question is, in case (2) how does Proxy AS1 inject a route into the
Internet
showing victim AS as the origin AS. The proxy AS1 already has a route for
the victim’s prefix from updates it got from one or more of its (AS1’s)
neighbors.
(Note that Proxy AS1 does not need to have a direct BGP peering with victim AS
although it can establish one if needed over a multi-hop TCP, but we don’t need
that here).
Let us say, the path that AS1 has for victim’s AS (or prefix) is AS6 AS9 AS2,
where AS2 is the victim’s ASN and AS9 and AS6 are some ASes in the middle.
All that the Proxy AS1 needs to do is modify the path and reduce it simply to
AS2.
This is a simple path modification (MITM). Pilosov-Kapela successfully demoed
a more complex BGP MITM back in 2008 on the live real Internet at Defcon.
By comparison, the path modification that the mitigator (proxy AS1) needs to do
seems feasible and simpler. Agree?
>
>>
>> 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,
The mitigator is *benevolently hijacking* the victim’s prefix (or subprefix)
today
to provide DDoS mitigation. Spoofing of victim’s AS may be used in the same
vein,
keeping mitigator’s update “Valid” when origin-only-validation is in use.
Your use of “and,” above is incorrect. It should be “or”.
Spoofing the Victim's Origin AS is applicable in the origin-validation-only
case,
not but in the path validation case (i.e. BGPSEC).
> b) Use pCount = 0 to avoid validating the AS_PATH signatures
Err… No. Where did you get that from?
pCount represents the AS prepend count (there is a pCount associated with each
AS).
pCount = 0 (in BGPSEC) simply means that the corresponding ASN must not be
counted in the path length count. Verifying the path signatures is still a
must.
Recall that pCount = 0 was introduced originally to accommodate
transparent router servers (IXP). In the present case, pCount = 0 helps with
not increasing the path length when victim’s ASN is to be included in the AS
path.
But pCount = 1 can also be used if you don’t care about the +1 increment
to the path length of the Proxy AS’s (mitigator’s) announcement.
> 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".
With pCount = 0 misunderstanding removed, I hope you now see that the
proposed solution is not simplistic as you might have thought.
The proposed solution is helping the DDoS mitigator announce/propagate
the victim’s prefix and stay “Valid”, while also avoiding having to
create/propagate
new RPKI objects in the emergency situation. That’s the goal, right?
Sriram
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
