Minutes IETF105: sidrops
|Meeting Minutes||SIDR Operations (sidrops) WG|
|Title||Minutes IETF105: sidrops|
|Other versions||plain text|
Administrative Jabber scribe: Warren Kumari Minute taker: Melchior Aelmans Chairs: Chris Morrow Keyur Patel Agenda: 0) Agenda bashing and Chair's slides - [5 minutes] 1) Alexander Azimov - [15 minutes] https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-profile-00/ 2) Daniel Kopp - [10 minutes] https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-validating-bgp-speaker-02/ 3) Tim Bruijnzeels - [15 minutes] https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal-03/ 4) Randy Bush - [10 minutes] draft-ymbk-sidrops-ov-egress draft-ymbk-sidrops-ov-signal Added to the agenda: Diversity (Terry Monderson) Alexander Azimov - https://tools.ietf.org/html/draft-ietf-sidrops-aspa-profile-00 Discussion: Job Snijders: Why did you put the derpricate-as-set-confed-set reference on this slide? Alexander: it's a good question, it's a question to you, to the WG. For a proper as-pat verification we cannot verify as-set segments because they are unordered. If we want to get fid of malicious activity that may happen in BGP we need to get rid of as-set and thats why it's here. i would like to know what happens to this draft and if anyone is happy to push it forward. from the security perspective we rely on the piece of this document. And the authors of this draft are here. Warren: the document is around for a long time. We've decied at some point we start another document at one point which depricated as-sets and atom aggregate. That seeems to be a much betting thing to do. It remove a lot of other things in BGP. Randy might have more to say. I believe the current version is ready to be adopted by someone to be adopted. Ki Sriram: I just want to add there is already a version of it which is at BCP which is converted to standards track. So hopefully the BCP is helpfull in the meantime but we can work on it so see if we can push it through to standards track in the meantime Alexander: I would be glad to see if to see if this peace of will get adopted. Ruediger: If nothing else happens as far as I can tell the interesting piece is at the end of the path; the as-set. The way it is usually constructed is not relevant here at all and if nothing else happens one would need to check that is can only happen at the end and then you could esessentially just just the regulair path. Assume that the first regulair as that shows up in the path and the set is hidden behind it is the origin. Becuase all the tricky stuff that happens inside the as-set doesn't matter. Alexander: yes I do agree with you. At the moment the certification doesn't say anything about if i said in the middel of the as-path is uhm if we have a forged as-path we should at least avoid as-sets in the middle. I do agree. Ruediger: as far as I've observed them they where never somewhere in the middle. There was a good reason for that. Unfortunately I don't have, well okay, let me put it into a question, would it improve the understanding of the whole thing if we did a part in the document that essentially reviels the concept of what is signed in the aspa's and the complext as1 use typically consfuses people who don't need to work with it and I think that the conceptiual data structure that is trnasmitted there and what supposed semantics are could be exposed much better and I assume the structure behind the structure and the actual encoding might change the concept thats being used Alexander: are you speaking about as 0? Rudiger: what is the concept being used? you are coding a set of asses and you do you strange trick in case you want to code an empty set. Kind of why not actually explain this and then code like it. Alexander: I remember we discussed privately, so my idea was when introducing as 0 document it was to design similair. I'm not sayaing, it is very simply from the perspective of coding, do you have sets or do you have as-set records. From implementation side it is nearly the same. Reudiger: all small matters of coding agree, for making people understand what they are supposed to do and to work well coding implementations can be an obtacle and yes I also have another hidden agenda. If we are actually coding sets of ASes that means you in the time, the stadard is being developed, in a matter of time, in a couple of months the concepts could be used by people that agree how to code in other ways available the sets of ases that actutally use the ways of technnique kind of imideately. Alexander: yeah but anyway generating for example as-path filtering using route <cards?> you will end up with some generator of your configuration. You will need to make sure you are using <clear?> to configurate..,., It should not matter if you are using a set of tuples. Ruediger: The issue here is much less the coding which may be slightly easier or harder, it doesn't matter. I agree handcoding stuff is out of the question. But making the concept that is used transparant to users actually is valuable because, while okay, with a little bit of coding the user interface can also represent concepts that is kind of hidden to whats happening underneath but that does not really help. Kind of for details, offline discussion, makes sense. Alexander: thank you ruediger Keyur Patel: if you take as-confeds out, do you want to propose what should be done if and as-confeds in encounter? Alexander: If speaking about any protection in malitious activity a forged as-set mitigates any protection. At the moment the draft says to thread it just like highjacks. Tim Bruijnzeels: the semantics are identical to what you have in OV hence that you argue to drop invalids. But when things are unknown thats okay? Alexander: Yes Tim: does the text states something about threating unverifyable things with suspision? Alexander: unverifyable is, I think valid Tim: thank you. I asked earlier, if there's a as that makes a signed statement, maybe we should think about how to make that object. Maybe I want to make 1 object that has everything in it and not risk that there are issues with a bunch of object that are withdrawn. Alexander: I'm not sure if I get the question, let's discuss offline. Geoff Huston: How can I be adjecent to an as-set and might it look like? Alexander: I like to state this one more time: the problem with as-set is that it is unordered. Geoff: it doesn't matter, it is never going to happen that everyone signs so you will have to have partials. Alexander: I'm not sure if I get your idea, I will try to reach you later Jared Mauch: I don't know how mayne adjacencies I have. I have an unknown number of. Alexander: how many upstreams do you have? We are talking about upstreams Jared: that might be possible to find out. Alexander: the only thing that aspa does, if you create a record it says who your upsteam is. Daniel Kopp - https://datatracker.ietf.org/doc/draft-ietf-sidrops-route-validating-bgp-speaker-02/ Discussion: Doug Montgomery: Whats the scenario where you get 2 validation results? Daniel: if your router is peering with different route servers and there's 2 giving you different result of the validation for a prefix. Chris Morrow: So, there's 2 routeservers at de-cix. I peer with both of then and they happen to be unsynced with their perspective of the rpki data, one says valid, one says unknown, what shoud I do? Daniel: that would be failure scenario Ruediger: these would be 2 different routes with different communities. I'm not aware of any configuration language to have appropriate polidy language? Doug: I think we have talked about this before but not in this context; you have no guarante that the highest value is valid? You have no guarentee that it has the most recent data, right? Daniel: basically you should favor the higher value Doug: I wasn't sugesting a race condition, I'm saying the idea that you choose the one with the more faverable validation result isn't a sign that you are choosing the one with the more faverable validation result isn't a sign that you are choosing the one with the more up to date RPKI information, right? Things could be effectively degrading. Daniel: it would be in favor of security I think in this case. Chris: I think Doug, your point is, as the data in the RPKI is changing over time, I may choose to authorize you to do this route today and Job tomorrow and not you tomorrow. And if the data at the 2 different route-servers is in a state where one has the old data and one has the new data I sertainly don't want the data with you in it anymore. <unidentified> We made an awful lot of test about that last year and you can have the following situation; let’s assume you have a router on the east coast and a router on the west coast. They exchange the data and they have the same path. Both have 2 validation caches. I don’t know which ion the validation cash has the most up to date data. I might that the one that results in a valid is more up to date than the one that has the other result. It also might be that the one has invalid has the more up to date data then the one with the valid so I cannot say just because out of security. Because it might be security that cause the prefix to be valid so what now? Daniel: okay I take this as a good comment for the draft. Job Snijders: In the case of failure in the OV process for instance, how do you define failure of the OV process? As for instance if the cache is empty policy will dictate all of them will become unknown and then omitting the community is a forge signal in this construct that contradicts with what we understand of what unknowns are or not found. So we cannot differentiate between a failure in the OV process. Daniel: yes I see the problem as well Job: a second comment: If the default is to reject invalids maybe you should remove the well-known invalid community and then only 2 communities are left; the unknowns and valids and at that point I kind of wonder what the use case is of this. Because I think it’s not very valuable and you should reconsider the words that “we can trust each other at an internet exchange”. I fully agree from a commercial incentive if I where looking for an internet exchange. But we in the transit world say “transit is what you trust”. Daniel: okay so you should sell…..anymore John Scudder: Now that you explained what the last bullet means I would like to agree with Ruediger that one route has one validation state. It doesn’t make sense talking about having multiple validation states for a route and as I understand it sounds to me it should be removed because it doesn’t make sense to say the route has 2 validation states. It only has one and it’s the one the route server told me. Daniel: okay thank you Randy Bush: I have problems with the trust model also but that’s been beaten to death. What you switch which community confuses me. We have a well-defined one but basically as you see the real problem that’s in the OV signalling draft is that as soon the community get to my router it is…..when it’s invalid. And the problem is that I want to close withdraw and we havent quite got the right semantics for that. Daniel: the community was changed because of the comments from the last meeting so I understand that this is the right way to go and the default thing that is also done at route server. Otherwise if we want to have extended communities like it’s done with the ibgp draft you have to implement all the policies and you have to wait like 10 years so we thought this is the way to go. Tim Bruijnzeels - https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal-03/ Eric Osterweil: I think this is really good. I like the fact that you do a lot of analysis and I would be happy to work with you if you want. Tim: Sure Randy: I would like to see early security area reviews and to suggest the chairs to find some friends over there. Chair: yes Rob Austein: I think prototyping is highly advisable. Maarten Artsen: You talked about keys being able to revoke other keys and your security considerations says that currently any key can revoke any other key. So I was thinking about these 2 and I’m wondering if you want to roll a key because you are not sure that it’s safe anymore for example. But that’s the property you are looking for? But it made me question how that works. I know that in the TLS working group I know that they tried to get some academics proof groups look at some parts of the protocol. I’m wondering if it’s useful to try and do that here with the RPKI bit to try and understand if the properties you are looking for are provided by the functionality you are modelling. And I’m not sure if anyone is willing and able to do that. But I guess that this is the time where you can easily fix oversight. Tim: thank you for the pointers so I can use good advise. What we had in mind that if you have an HSM you usually well protected against key theft but you might still want to do planned rolls because you might want to change hardware and you can still loose the key as well. A lot of this relies on procedures. If all keys can remove each other then you just need to have only one of these keys to … and clearly that can introduce bigger security risks so I think there’ s tradeoff here and I’m not sure I have all the answers but I hope the help of HSMs can help in that regard and strong processes. You need to have especially processes. Sandy Murphy: I have been impressed by the amount of effort it took to do the DNSSEC key role so this is a really goo idea to get an early start. Thank you very much for starting the work. I also remember the difficulty there was in the SIDROPS WG to define the algorithm to change documents so what happens if your key role is also an algorithm role? Tim: I don’t know Sandy: okay good answer Rob: I haven’t reread this recently. One of the things that was a consideration to publish keys that was the ability to pre-publish keys before using them. Thats basically because no-one knows how to do an emergency key-role. We probably want to put something in it to do that. Tim: fair enough Randy Bush - draft-ymbk-sidrops-ov-signal John: I don’t think I like it but I will think about it for a while. Job: So you are kind of sticking withdrawals for off link peers into a bop community? Because what the Route Reflector thinks its invalid it send a signal back to the spoke that could be a well known community or a attribute…. Randy: the community is already documented and defined. Just saying the semantics aren’t… Job: … treads what it received from the ebpg peer as a withdraw and then it will send withdrawals to the other route servers. Keyur: No, route reflector when it receives a route from it’s clients it will run a best path and will announce a best path. When it does the community it tags on top of it says what is wrong with it. Now route reflector could say path 1 is the best but path 4 had a bad community. So it can do add-path and say this wrong, take it back. The net result is the same. Job: The spoke receives the signal, then what should it do, perform OV? Randy: the point is, when the spoke receives the signal it withdraws the invalid as if it had detected it but it has no cache feeding it. Job: in other words this is signalling withdraws over BGP communities? Randy: it is signalling asking to withdraw Jared Mauch: And then it decides I have seen this again and I’m going to send it back up. This sounds scary and messy. Job: if we are going to modify the edges to accommodate the behavior then why not just implement OV? Randy: Others want to have centralised control. Randy Bush - draft-ymbk-sidrops-ov-egress Job: go on Terry Manderson - Diversity Conversation Florian: It turns out that even if you don’t have a ROA you still have a problem because someone can’t get a ROA. Ben Maddison: I presume the single operator you refer to is ARIN? Terry: It doesn’t matter who it is. Ben: This is presumably assassinated by the fact that all 5 are claiming root in the root CA? Terry: not necessary. It would actually also exist if there was a single trust anchor. And it could be worse. Ben: So you don’t see this being improved from a diversity perspective by having the numbers from which the root server come from more widely spread amongst the…. Terry: I don’t see it…it’s better but it’s not ideal in my opinion. Job: I have trouble grasping the problem; there are 5 root certificates and 26 prefixes and you can distribute the 26 under the 5 tals. That is not enough diversity? Chris: can you do the numbers for your first 2 RSEP documents please? Terry: 0 21 Chris: no not those numbers; the internal numbers like the first one is it’s okay if the first root server Terry: ah yeah, the first one is it’s okay if there’s one fails the second one is principle that sad for the root server operators and that is that the root server operators will have diversity in their operations inclusive network and stuff like that. Job: so if you sign half of them, not sign the other half and distribute amongst the multiple RIRs you’re done right? Terry: I don’t know it that the answer that SIDROPS would recommend? Job: is that within our mandate? Terry: this is where you operate RPKI and SIDR and stuff. This is where your expertise is Job: In that case I would recommend you try to transfer at least 1 IPv6 prefix to another region as an experiment to see if you can obtain access to other certificates Carlos: we will happily welcome you guys. We have policies that allow us to assign prefixes for critical infrastructure that can be used outside of you region. And I believe the other 4 have similar policies.I don’t believe this is a problem for us to solve. I think if you have 9 prefixes within. A single RIR you guys are a bit weak on the diversity aspect that you are defending. I don’t know what the solution is. I mean you could role IP’s in some of the other root servers and distribute them amongst the RIR’s. You can get new space from us. You could transfer like Job said. You could create more diversity in root server operations. Terry: maybe someone should write a document that defines some things that you should do. There is no advise about this to date. Chris: maybe the issue is a general network operations problem? Terry: I wasn’t making that point but fair. Robert Kisteleki: 3 things; 1. I don’t think the root servers are any special in this context. 2. No operator can be worse of then today if they also have Roa’s and RPKI. They may be better of but they won’t be worse off in case of attacks. I’m happy to talk about it. 3. Root operators already sync on protocols and all you do so you might want to do IPx or something. Doug: just to be clear so you are afraid of ROAs being created that cause other folks to drop your route? Terry: it could be anything, it could be operational failure Doug: which causes your resources to become unknown? Terry: it becomes invalid Doug: so people who filter on invalid can’t reach you on that address Terry: correct. Especially if it’s transit that is filtering Randy: I would want to refer you to a presentation that is about how to escape ARIN. All my resources are at RIPE. Terry: I didn’t mean this to be a beat up of any RIR Randy: what I’m saying is that some can move Terry: The point is that the diversity is 5. Rob Austein: you are not going to settle this today. I think you need to make a distinction between reliability and availability. You can probably survive an outage of RPKI not being updated. So you might want to do the numbers on how long an outage is acceptable. Geoff Huston: You have raised an interesting issue. They are great topics. You should consider from the perspective from all 12 of you what you should need to get diversity and maximum availability and performance. Maybe invoke experts from RSEP. It’s difficult for this group to advise in isolation. I’m saying not here and not now. Terry: Where do you think I’m going next? Doug: it seems like your risk is the same no matter what decision you take because its the other people doing validation. If a CA is compromised and someone creates a wrong ROA for your resources whether you take action or not? Terry: correct Doug: right. Seem like you can make a decision whether you fear route hijacks to the routes more than you do compromise massive failure in RPKI. Terry: I think I’ve done enough here; I’ve raised awareness Job: what would you propose as follow up on this? Is there a WG or institution working on this? If we have a great idea where do we send this? Terry: my next steps is to raise it at RSEP. I’m also member so it will be raised there. It might be raised in other parts of ICANN. There’s additional stuff coming through but I thought it was good to raise it here.