> I don't have plans to be at NANOG in February, so perhaps IETF in March?
Yes, I plan to attend the IETF in March. > --snip-- >> (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). > Would it be possible to leave the BGP session intact from their CE to your PE? If not, can a new BGP session (possibly over a TCP session that may go over multiple physical hops if necessary) be set up between your PE and the customer? Customer could even use a simple PC emulating a BGP router to do this. Then they can originate their own prefix and directly pass the announcement to your PE; the update could be unsigned (when there is origin-only validation) or signed in the future (when there is path validation). > > >> 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". > Please see my comment below with you new example. > > >> >> 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? > In the ROA, there is an expression of intent, but still origin-only-validation leaves door open for faked origin announcements. Third party would always treat that type of announcement as Valid provided maxlength is not violated (in the origin-only-validation case). It is the victim who knows it was a “benevolent” act by their mitigator, and therefore does not raise an alarm. This discussion is moot in the path validation case. > >> 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? When there is path validation, obviously the mitigator cannot spoof the victim’s AS; it is not possible. The mitigator can only rely on receiving a signed update from the victim; please see more elaborate comment below. > > >>> 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 | > +------+ +------+ > > The WG has generally held the opinion that one organization handing its private key to another is not a good practice. So I think the solution has to be of a different nature. We have to ask if it would be possible (as part of the mitigation /service recovery strategy) to quickly set up a BGPSEC session between the mitigator and the victim in cases when one did not exist already? This BGPSEC session does not have to be over a single physical hop; it can be set up over a TCP session that goes over multiple physical hops. The equipment on the victim’s side can simply be a PC that emulates a BGPSEC router or it could be their CE. Do you think this is workable? Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
