I agree with your comment about a conversation at Nanog in February, sounds like a great idea.
Comments inline below. Thanks, Bryan On Dec 20, 2012, at 10:39 AM, "Sriram, Kotikalapudi" <kotikalapudi.sri...@nist.gov> wrote: >> >> 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? > Sure, but isn't Eric's point that there is no ROA in this case (#2) and if propagation times are too large (days or weeks) then it doesn't really help with the DDoS mitigation? I am also curious about AS's that are direct peers of AS2. They might not necessarily select the mitigating AS because they are also one hop away and the tie breaking criteria will be used, 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, > > 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 > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
