On Dec 20, 2012, at 8:39 AM, "Sriram, Kotikalapudi" <[email protected]> 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?).
I don't have plans to be at NANOG in February, so perhaps IETF in March? > --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 Assume the answer is: No. > (2) is being established in emergency after the victim came under attack and > made a panic phone call to the DDoS mitigator (Proxy AS1)? Yes. > 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? Theoretically, yes. /Assuming/ they planned ahead. However, I would note that the use case I've outlined above is more broad than 'just' DDoS attack. Specifically, think of "natural or man-made disasters". In the latter case, it's often the case that a customer's primary DataCenter is taken offline and, although they [may] have a secondary/backup DataCenter, they hadn't adequately provisioned capacity into it. In those cases, the answer is, generally, to bypass the undersized physical equipment/tail-circuit/whatever in order to restore service as quickly as possible. In the example diagram I've highlighted above, this could involve removing an undersized CE router from the physical path between my PE and their server farm, (because it's physical interfaces, processing power, whatever are not adequately sized). Although you would think that with the recent natural/man-made disasters we've witnessed (Hurricane Sandy being the most recent), people would get better at "planning ahead", but unfortunately that doesn't seem to be panning out. > 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? In the case of DDoS mitigation, yes. In the case, where I am helping restore service *after* a natural/man-made disaster or flash crowd/traffic, that's not the case. I'm just sinking/sourcing traffic to them to get them back online as quickly as possible. > 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? I disagree. As I stated previously, commercial routers *DO NOT* allow me to originate the Victim's IP prefix from the Victim's AS. My router (AS1) only allows me to originate IP prefixes from AS1. My router (AS1) does not allow me to originate an IP prefix from some random AS: AS2, etc. As I also stated, I firmly believe that's a *security* feature, not a "bug". >>> 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. Hrm, "benevolently" implies _intent_ ... yes? I thought "intent" was strictly verboten in this WG? So, how will third-parties in a BGPSEC world know that the intent is "benevolent" vs. "malevolent" hijacking? > 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). Why? >> 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. OK, my apologies for the misunderstanding. But, this leads me back to the question you never answered in one of my previous e-mails on this topic. Let me draw a little picture to make that question more clear. Again, I'm going with the scenario that you envision is theoretically possible (under duress), which is that there is the following topology. (Note, this is not applicable to the other scenario I outlined above where no CE router exists during restoration of service after a natural/man-made disaster). After a DDoS attack has started to occur, the Victim has called up a DDoS scrubbing service provider and said "Help", with no prior business relationship in place. In this case, let's assume the DDoS scrubbing provider already has a "CE-1" router, located in the DDoS scrubbing provider's DataCenter(s), sitting idle which will benevolently stand in on behalf of the "Victim AS" and will be used to inject the Victim's IP prefix(es) with the correct, original Origin_AS. In this case, "PE-1" is owned/operated by the DDoS scrubbing provider and has "Proxy AS". IOW, you can think of "Proxy AS" as a brand-new "Transit Provider" to the "Victim AS". Again, since there was no prior business relationships and time is of the essence, you have to use the HW already deployed in the diagram below. I agree that, strictly from the PoV of Origin Validation, CE-1 can originate the Victim IP prefix with the correct Origin_AS and Origin Validation will work OK -- even though, in this case, everyone will have no idea if that's what is intended or not. However, my question above is really about Path Validation, specific to BGPSEC. In this case, how does the "Victim AS" get their (private?) signing keys deployed /within/ CE-1 of the DDoS scrubbing provider? Isn't that required in order for CE-1 to properly sign the AS_PATH Signature before transmittal to PE-1, in order that receivers of this BGP UPDATE will observe a valid BGP AS_PATH Signature? DDoS Scrubbing Provider "Proxy AS" "Vicim AS" AS1 AS2 +------+ +------+ | PE-1 |-------| CE-1 | +------+ +------+ >> 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. I'm still not here, yet. > 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? Yes. -shane _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
