Hi Demian, nice work. I'm a little bit wondering about the classification. Can you be a bit more specific how do you define "Object related" and "Systems related"?
For example, the "Short Lifetime Attack" is categorized under "Systems related". However, it is directly related to the configuration of the signed object; on the other hand, it harms the RP system. Does the classification reflects (a) which part of the system is harmed, (b) which part is used to introduce problems, or (c) a mixture? I think a clearer separation would be helpful. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehli...@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Mon, 13 Jan 2014, Demian Rosenkranz wrote: > Hello, > > as some of you know, I'm writing my master thesis about RPKI at Deutsche > Telekom (Rüdiger Volk). Especially I try to identify the "problems (attack, > misconfiguration, ...)" of using RPKI as a relying party/resource owner and > try to find ways to identify if such a "problem" arises (i.e. competing ROAs). > Furthermore I want to give proposals on how to proceed if a "problem" arises. > To sum it up, a RP should use the RPKI as a reliable tool to improve it's > routing. I hope this thesis helps to reduce the concerns of some RPs of using > RPKI for securing inter-domain routing. > > The following classification lists the groups of problems I've identified > including a short description. If possible, I used terms which are used in > SIDR drafts/RFCs. It would be great to get some feedback to this > classification. I guess most of you prefer textual description, so I tried to > represent it in textual form. Additionally, you can find a jpg attached. > > Classification of "problems" > 1. Incorrect representation of RPs/ROs INRs at "RPKI layer": The initial > transformation of RP/Resource Owner INRs as RPKI objects is not correct. > 2. Incorrect/untrustworthy/suspicious RPKI information > 2.1 Object related > 2.1.1 Competing Attack: Router certificate: ASN competes with existing router > certificate; Other Objects: IP-Range competes with existing objects (In my > opinion, certificates can also compete with other certs because of their X.509 > extensions. Of course, at the end the ROA causes the problem but it could be > kind of an early warning system if competing certificates are identified --> > Should a doctor try to take care of the cause or just try to allay the pain?). > 2.1.2 Whacked Objects: Object transition which results in a route transition > from valid to missing or invalid. > 2.1.3 Non-compliance: Non-compliance of RPKI objects can cause bad behavior of > RP software. Weak alg./key length could result in a downgrade attack. (There > are syntactical checks, but for the sake of completeness and because of > possible implementation mistakes it's also included) > 2.1.4 Expiring object: Check if objects are almost expired/forgotten. Can > cause unwanted routing behavior. > 2.2 System related > 2.2.1 Replay attack:A whole old dataset could replace a newer one and could be > still valid. > 2.2.2 Short lifetime attack: Recurring ROA sets with short lifetimes could > overload the RP software because of it's cryptographic checks. > 2.2.3 Incomplete amount of objects: Incompleteness of RPKI objects could > affect the global routing behavior. > 2.2.4 repository availability:A DoS attack could affect the availability of > the Repository. > > > Kind regards > > > Demian Rosenkranz >
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
