Minutes Trivia Agenda bashing 0:15: Sandy talking about AS Path parameters pcount0, signatures on As Path. protocol specification was changed to capture all the semantics from the BGPSec attribute. Doing away with the entire As Path parameter is not acceptable as was discussed on the mailing list. On the boundary between a BGPSec speaking As and a non BGPSec speaking AS we reconstruct the classic ASpath from the bgpsecattribute. 9:50 Randy asks question about what are the problems we have today with knowing what path has been followed. Are signatures sufficient Randy eludes to the discussion that occured on the mailing list a week before on confederations. Sriram Slide #7 Confed sequence talks about AS confed configuration, signing example. Randy objects to pcount 0. Sandy, Wes George weighs in. Everyone agrees to use pcount 1. resolved As confederation discussion 20:35: Removing the signatures and ASNs that are internal to the confed at the edge of the router. Sandy: at the exit point,you assume you know the public identity of the As, and you step back until AS recognizes the public AS (something that is signing forward). Ruediger: Loops is a showstopper. Randy: If you go backwards (leftwards) stripping signatures until you reach the first public AS, then we wont have a problem. Reminds that John scudder implementation works in a stub stub stub core. Randy summarizes: For confeds, everyone signs on exit. Exit AS knows all the ASes and strips or goes leftwards by removing all signatures until it reaches the 1st signature forward andthen forward signs (pubic AS). Sandy's comment: BGPSec configs allow loops. 31:00 discussion on potential of abuse in confed Ruediger:more discussion on loops in confeds. consider a configuration where the confederation is not completely bgpsec. Some additional work is required to be done. Randy explains how it will work. A correct confed sequence is required. Wes George and Brian Weis weigh in. 45:30 Sandy asks a question for operators: Do we have to do a unique set of operations when leaving a confed or not? said yes. Ruediger (operator answer): Yes. Not convinced that everyone keeps the information of all the partipants in the confed for a large one, so we go with a marking operation. New additions, how are they dealt with? Sandy:Warren says that new additions will cause them to have to tell all the other members. No other choice. Randy asking everyone whether they understood the ASPAth. Summarizes: In a confed, every AS signs normally, when you enter the As the first AS within the confederation sets a flag in the flags field of signature block that says I am the entrance of the confederation, the data wanders around wonderfully in the confed and everyone signs it. At the exit the router where it is existing looks backwards in the AS sequence until it finds the first instance of that flag. it strips that sig and all subseq sigs and forward sings to the next As.While this little packet is traversing the As ifit should hit a peering where the deestination isan external As is not bgpsec capable, just as normal it must recostruct the classic AS-As path including using the going left to find the flag bit to find the sequence. Question from jabber room Jayb: suppose a bgpsec router that knows it's not in a confed sees the "start of confed" flag. should we specify the action to take in that case?" ruediger: if someone not in a confed sees a confed flag,it should mark it as invalid, just as when someone sees two flags set, which is invalid. Brian Weis suggests having a common algorithm to convert back to an As Path irrespective of whether inside a confed or not. more discussion on flag setting at entrance and exits. No suport for nested configurations. ===== ===== 1:06 Aliasing Sandy says Use of pcount = 0 does not require changes to the protocol. Warren describes What happens when we have aliasing? Currently, aliasing bob thinks you are called fred but when you talk to the rest of the world you are joe: So, how is that handled in BGPsec? explains with example. Warren's concern is it comes back to the lets use pCount=0 hammer. MOre people means more usage. Sriram on Slide 9. Explains an example of aliasing. As2--> AS3-- >AS4, with AS2 setting Pcount=0. Reudiger discusses the example on the slide further. He says ambulating (?) alias AS is visible in path as it is pushed down to customer while other way around AS3 is not visible but the customer As is published. Customer will have to set pcap=0 which is not allowed. AS4 not expecting transparent then will get angry. Randy and Warren join the discussion. Result is that of discussion was that an internal AS cannot set pcount= 0. These rules are made for protection of everybody. 1:13 Sandy asks for a generic diagram for better explanation in future. Sriram asks about AS migration vs. Aliasing. Reudiger clarifies that AS migration is a use case and Aliasing is a technique, when asked whether AS migration and Aliasing are one and the same (question asked by Sandy). Sandy asks a question about aliasing: when you have two ASes under similar administrative control and you will use an AS aliasing in the future. where does this get set? Randy replies single router configuration, Reudiger explains that it will be on the router that has a real AS and a fake AS. Wes George disagrees with the assumption that AS2 is real and AS3 is fake, they can both be real. The problem with this approach (using the same approach as with confederations) is that when you forward sign AS2, and strip AS2 from there the forward signing is now broken. That cannot necessarily work and is hence a different problem. If no migration is required, then no issues. Today how it works is that the right machinery just munges the AS Paths in and goodness comes out of the other side. Question from Sandra Murphy: When you set up the aliasing are you setting up aliasing between AS2 and 3? Ruediger only on a single side of that session where two ASes are involved. 1:19 pcount=0 discussion comes up, this discussion belongs in the use cases document. Warren says you do not want to explore all possible horrible vendor knobs. Wes will get with Shane and see if the understanding and concerns regarding the use case are correct. Warren will work with Wes to flesh out the semantics. More discussion on pcount=0. Doug Montgomery makes a comment on pcount=0. Discussion on going ahead with bgpsec attributes without the AS_Path attribute. Sandy mentioned that John (Scudder?) felt that AS_Path should be in the document but was aware of the problems associated with doing that. In summary, Randy said that here is where we should leave this discussion today. These are the scanarios that might require rechaining the AS path. We have not seen that requirement. We think that we can do them, here's how we can do them. They do not require the AS_path and therefore we do not feel AS_Path will go back into the document. Randy asked if anyone had any strong objections to this. No objections were voiced in the room or on the phone. Matt Lepinksi said we will make the document more clear with respect to AS_Path. 1:50 Next topic: Keying and Rekeying Rob Austein asks if we can get away with just generating keys on the router? Randy Bush and Rob Austein talked about people not going to spend the money to do it the cryptographically pure way, therefore hotswappable looks the way to go. Discussion on eeprom between Warren, Randy. Brian discusses the WG document -01 which had a few changes based on discussions in Paris. Warren asks about keeping track of the state of documents in the working group, Sandy refers to the wiki page. Randy Bush: We should recommend that the second certificate should always be provisioned. All you will have to do is revoke a new one (the third) Brian agrees. Asks what is the maximum number of keys? Warren says some people will disagree because they will have twice as much keying information sitting around that they have to keep track of. If someone has compromised the first they have probably compromised the second. Randy Bush feels that adding the second set is no worse. Sean Turner says that all you can say is that you must keep the private secret. Sriram said that everytime you roll the key you need to repropagate all prefixes in your rib. You do have a choice for the frequently rolling keys. You only propagate what you originate. If the key doesnt change, then nothing changes. Definition of replay was set as send update to peer, then withdraw, then the peer either suppresses the withdraw or sends update further along. Sriram wants to note that we have not solved the problem of a single prefix withdraw. Brian Weiss: It does not solve all possible replays. Next topic: Performance considerations Andree Toonk: Shared some observations from using the RIPE validator against various repositories. Fairly high rate of failure synching to repository. How long can a repository be off line? Timeouts , certificate revocation lists that are stale, validator declared everything invalid. Sometimes several days when repositories are unavailable. Rob Austein talks about the caching structure. Rsync was a good first try but it is showing some issues. We are alot further than we would have been without it. But, it may be time to reconsider that. With rsync, no way to amortize the synching costs with the flat file structures. We do not know the cost of the failures we are seeing. We aren't getting help with debugging. There is speculation that IPv6 might have something to do it. The validators (RIPE's,BBN's and Rob's) need more data and troubleshooting. Sriram Slide #2 Acceptable convergence time, how long does it take to converge no bgpsec. They use an OTS router XCJ turned up, same no. of routes, AS_Paths, etc. and get average convergence rates. Wes indicates that how long does it take to converge from a session reset, is the metric. Randy Bush says for CRJ 3 hours to boot, 3 minutes to converge. Discussion of what should be reasonably measured. What is the definition of convergence in this context? You do not need to validate to propagate (says the spec) What you need to do to prevent a real mess is not strip. (Lengthy discussion on performance issues.) lazy vs strict more operation. impacts on reconvergence. Doug Montgomery says that the assumption here is that lazy is not a steady state, but a temporary state on reset. Doug mentions that after converging there might be a lot of junk coming in. Randy says that if he sent rubbish it will be caught at the next router. Brian asks how will the next router know that it is rubbish? Reudiger raises question about delays and if large sessions occur Sandy asks when does one go from lazy mode to strict mode? Wes George: convergence does not equal convergent filters. Need to articulate that and the expectation. Cert and security side not measuring time but giving implementers a time about how long their lazy state is going to be. Sandy brings up the discussion about future meetings. End of meeting.