--------- SIDR --------- **** WG status (Sandy Murphy) PFX-Validate has been through last call and been updated. -- Please read through this draft and indicate whether your comments have been adequately addressed 11 drafts in RFC Editor's Queue ... Yay!! Ghostbusters draft is in Last Call, please send comments to the list by August 3. **** Algorithm Agility (Roque Gagliano) -- Authors claim that draft is now ready for WGLC Sandy requests more reviewers because it's a vital piece of work **** Publication Protocol (Rob Austein) -- The protocol changes in this version were to make it so we don't have to update the protocol document every time we add a new signed object (That is, there is now a generic publish operation) -- Not yet ready for WGLC Normative changes were just made to the protocol Needs another revision [e.g., security considerations not up to date] Q&A -- Sandy M: about communication protection -- Rob A: same secure communication as other parts of the system **** SIDR Usecases (Terry Manderson) -- Very few (maybe four) have read the -02 version. There has not been much discussion of this draft on the list -- Authors request WGLC on this draft If you haven't yet read the -02 version, now would be a great time to do so. **** BGPSEC Protocol (Matt Lepinski) all changes small Q&A -- Wes George: Do we use the same algorithms for BGPSEC and RPKI? how does this interact with origin validation….can we leverage that work? Can we leverage the algorithm transition work? Answer: Currently alg doc allows for decoupling of algs between the two. Not sure if its valuable to have that be consistent or not. But that's a decision the working group needs to make going forward We might want to use different algorithms with BGPSEC to use something with shorter signatures than RSA. bgpsec needs alg identifier where origin does not **** BGPSEC Beaconing (Randy Bush) -- Suggests in Presentation that Expire Time be configured in units of days (since we really don't like the amount of traffic created when we use hours) -- Beacon is coming from the origin -- Not a goal to eliminate the reply attack (we don't know how to do this) Just to reduce the window of vulnerability -- Claim that Multi-Beaconing solves only a small corner-case Fine to solve if it is cheap, but it isn't -- Origin Beaconing O(once a day) costs only a few percent in BGP noise increase and prevents operations pain associated with trying to deal with replay through manual RPKI mechanisms questions: -- Wes G: Regular beaconing question. The beacon has to be propagate from the origin. Is there a security concern if someone in the middle decides repeatedly to drop (either intentionally or accidentally) your beacon? Couldn't this reduce the value of Beaconing -- Randy B: Accidental drops are taken care of because current suggestion is that you beacon at least twice during the validity period. Deliberate drops are no greater risk – Today the person that can drop the beacon could also just issue a withdraw. -- Wes G: since beacons don't cover that case, question of worth -- Randy B: I am not married to beacons, I'm willing to give them up We can remove them if the group determines the benefit isn't worth it -- Jeff Haas: Beacons are important enough to be worth doing Policy to prefer more fresh (based on expire time) routes is a good option for operators to have so offender gets no benefit from announcing stale updates. -- Randy: reasonable point **** RPKI MIB Modules (Bert Wijnen) -- Authors request a call for working group adoption Questions: -- Paul Hoffman: Do the router vendors want this? In particular, do they want to be doing this for control (read/write)? -- Randy B: The project was started by one router vendor, and here is another at the microphone line (see below) -- Jeff H (Juniper): I would be concerned about having SNMP affecting your validation state. I don't see any terrible good use-case for having a write-version of the mib From security standpoint, this is meant to show output of rpki router protocol. -- Rob A: I am not a router vendor, up to the vendors to put in the mib or Not, but I would very much like this to be read-only -- Warren Kumari: most operators believe that SNMP is a "Monitoring Protocol" and not a "Management Protocol" -- Sandy M: last line mentions validity – is that the ROA validity or the BGP route validity? -- Rob A: This is just the stuff that makes it through the RPKI RTR protocol after ROA goop is stripped off….go either way on if validity part belongs here -- Jeff H: This ROA-table is the output of the RPKI RTR, letting you know what your local cache is If you want to know whether a particular BGP route has passed validation, it would be in a different table (maybe the BGP MIB) -- John Scudder: The last entry in the ROATableEntry should be removed -- Bert W: We are getting into quite a bit of detail here, if there is interest we should adopt the document and discuss this further on the list without bgpVRTValid line you really have nothing here -- Rob A: you do have something even if you drop the VRTValid line -- Randy B: Supports Read-Only MIBs (as he has for over a decade) I don't mind if that Integer at the end of the ROATableEntry goes away -- Doug Montgomery: You seem to be missing the max length of the ROA, the Integer on the last line can be re-purposed for that **** Route Servers and BGPSEC (Chris Hall) -- Chris is working on a Quagga implementation for EURO-IX for use as a route server -- Claim: A route server these days is standard equipment for an Internet Exchange -- IXPs may be in the vanguard of BGPSEC adoption, therefore support for Route Servers must be a REQUIREMENT for BGPSEC -- Proposal 1: Proxy signing on behalf of its clients Drawback: Requires complete trust in the RS administrator (RS administrators are generally Good Chaps) -- Proposal 2: Route Server signs for itself Drawback: Route sever is not invisible ... it is very bad if the presence of a route server affects the AS-PATH length Not clear whether it is a deal breaker to reveal the route server's presence without any affect on the AS-PATH -- Proposal 3: Client signs for every possible destination Drawback: Extra mechanisms needed to let the client know who the destination ASes are makes it more difficult to connect to a route server -- Point for discussion: Should support for Route Servers be a requirement for BGPSEC? Questions -- Randy B: "What is Invisibility?" What we want as operators is that whether we use a route server in the control plane should not affect downstream best path decisions Let's cause this property "translucent" This is entirely different than being completely invisible The contract of BGPSEC is that everything that is in the control-plane path must be verifiable I don't think you can have invisibility and BGPSEC, it's dishonest and BGPSEC is about honesty The approach of sharing private keys with the route server is impossible because then it is no longer a "private" key -- Jeff H: Why does the route server need to get involved in all in the signature chain? ANS: That would be the third option -- Jeff H: I don't believe you need the forward signature (in its current form) for security in the case of route servers. Things that actually care about validity won't care about the route server being involved. -- Randy B: The basis of the protocol is forward signing. what would the destination AS be in that situation. -- Jeff H: Router vendors already put in special cases to deal with Route Servers, why can't we add a special case in BGPSEC. -- Rob Shakir : The point of invisibility is about forwarding plane and not control plane. If I care whether you are using a routing server at a large IXP, there are public lists in most cases where you can learn this out-of-band today -- Warren K: You don't explain about option 3 in your slides. The route servers use some new protocol mechanism to assist the routers connected to the route-server to set up BGP connections with the other peers that use the route server. Just have route server announce all potential peers and have the peering setup happen directly. That is, the route server helps the peers to find each other, but then it is not in the control path for the BGP messages sent between peers on the BGP sessions once they are setup. -- Randy B: Warren's suggestion requires some additional thought Where there are route servers there are multi-lateral peering agreement so you may not know all the possible peering routers and ASes at any given time. -- Steve K: For Proposal 1, you don't need to give THE private key to the route server. You can create a new router cert just for the route server and declare it as part of your AS This is still bad, but its not as bad as giving the route server the same key as you give your own routers (so it's better from a revocation point of view, but still not a wonderful idea) -- Keyur P: Warren's suggestion is good, we should think about that some more. It would require not only auto-discovery of peers, Warren is suggesting you replace a star topology with a full mesh -- Warren: This is a feature not a bug -- Randy: No, it's not a feature -- Doug Montgomery: without forward signing you have very simply cut and paste -- attack exposure -- Rob A: At least in Warren's suggestion the trust properties are right, the route server is informing you about the possible peers who are present. The trust model of bgpsec is intact since the route server is really not involved in the bgp session/control plane. -- Roque Gagliano: Could we have a special EKU indicating that a BGPSEC cert corresponds to a route server Then when I do the BGPSEC validation, we also configure so that if the flag is set then its okay to remove from the AS-PATH -- Randy B/Sandy M: Who attests to this flag in the certificate? Isn't there a vector for attack here? -- Randy B: Support for "Transparent/Translucent" route servers should be a Requirement. Minute taker note: No one objects to the requirement for support of "Transparent/Translucent" route servers !!!! -- Randy B: Note that many people use route servers because they believe their routers cannot scale to the number of BGP sessions required to peer with everyone at an IXP. Warren's suggestion [above] runs into this rock **** Prepending and Transparency (Doug Montgomery) -- Strawman proposal for how to accommodate "Transparent" ASes – use prepend count of zero to represent AS that does not appear in AS_PATH Questions: -- (missed speaker): question about using AS0. Ans: the "0" is a subscript only. -- Jeff H: The prepend zero solves the route server issue quite well You support Egress prepending but not Ingress prepending (which is more route) -- Jacob Heitz : How about two AS-PATHs, one for ASes that touch the update message and another for touching the security attributes. -- John S: Supports this idea (strawman proposal) Slowly stumbling towards what's signed is first class path, then you have second path for forwarding. Also has the nice property of solving the problem where Route Servers violate protocol correctness by not doing loop suppression -- Jeff H: For backwards compatibility, it would be nice to keep the old AS-PATH for loop detection and AS-PATH length computation It would be good to put the ASes into the Signatures attribute even though it's redundant -- Doug M: If we don't try to protect the exact number of prepends, then we support Ingress prepending and things get simpler Is it really a requirement to protect the exact number of prepends -- Jeff H: I do not believe this is a requirement [to protect the exact number of prepends] [This would be a good topic for discussion on the list, as to whether this is a requirement] -- Randy B: Ingress AS prepending is a lie I have my own policy knobs to bias within my AS -- Jeff H: "People are fond of their various forms of kink" They have other knobs, but they all have their favorite form of Kink People do use incoming AS path prepending over other mechanisms to influence internal policy -- John S: Prepending is a form of policy We should keep out of scope protecting things which just affect policy The other extreme of protecting all things that affect policy is not a direction that I want to go to -- Danny: I don't think we can do things that ignore policy if it will break things that affect active routing on the Internet (that is, respectfully disagreeing with John) **** RPKI-RTR Library Implementation (Matthias Waehlisch) -- Project website: http://rpki.realmv6.org Website has documentation on the current API Working group is encouraged to comment on the current API -- Question: What is the license? Answer: GPL **** RIB-Size Estimates (Sriram Kotikalapudi) -- Paul H: In the stuff that you didn't show, did you consider the effects of decreasing the size of their RSA keys? Would RSA 1024 buy you much? -- Sriram K: it (the tool) does allow you to adjust -- Randy B: RAM is cheap The problem is that routers are 32-bit not 64-bit In this time-frame, routers will need to change to 64-bit addressing Paul, Shorter key length doesn't help, there is a big step function here (and RSA 1024 is still beyond the 32-bit step) -- Warren: If you are interested in this stuff, start telling your router vendor now that you want 64-bit addressing! -- Rob Shakir: Space on your control plane board is not cheap, there is opportunity cost **** BGPSEC Design Choices (Sriram Kotikalapudi) -- Note: Authors are not requesting working group adoption This is will stay as an individual draft and authors plan to publish as an informational RFC **** Resource Transfer (Randy Bush) -- Presented possible RPKI procedure for transfer of resources -- Request for the RIRs to share their plans for how they intend to make Resource Transfer with the RPKI work in practice Question: -- Paul Hoffman: clarifying that the swing point is the lowest possible point that agrees to be the swing point -- Randy B: in 2006 he suggested the torn euro protocol to signal swing point between allocators -- Sandy M: Is there need for any change to the RPKI for this procedure? A: No. **** D-BGP (Mingui Zhang) **** FS-BGP (Yang Xiang) Wes G: It would be helpful if you could re-spin this as a way to update/improve the current design it would be helpful We are too far along in writing code to have a straight-up beauty contest Kent: Not clear that this work meets the requirements for AS-PATH validation in the SIDR charter In particular, it seems that it allows feasible but un-announced paths to be valid Concern that the characterization of replay attacks against BGPSEC is over-simplified Sandy M: Are you proposing this as an alternative to the existing proposal or as an extension to the existing proposal? A: An alternative Sandy M: The routing ADs have indicated they are not willing to expand the Charter to take on additional work and that requests for adding new topics to the existing charter should be directed to them.