hi russ, > 3.3 As cryptographic payloads and loading on routers are likely to > seriously increase, a BGPsec design may require use of new hardware. > It must be possible to build routers that do BGPsec with within > acceptable (to operators) bounds of cost and performance. > > This should be left out of any requirements document, and various > proposed system compared based on their costs and deployment > difficulty.
i take your point. the intent was that compatibility with current hardware abilities is not a requirement that this document imposes on a solution. it is quite likely that provider routers will need crypto assist and more ram. though one hope that the stub customer edge will not. and the operators with whom we discussed (note that i am an operator, not a vendor with a bad habit of speaking for operators) this thought that this needed to be said from both ends of the scale. we did not want the future security constrained by a 7200, nor did we want an explosion in costs. as dollars are the bottom line in our capitalist culture, constraining them seems quite reasonable. and we will try to phrase better in the next version, we promise :) > 3.7 If message signing increases message size, the 4096 byte limit on > BGP PDU size MAY be removed. > > Has anyone done any analysis of the impact of increasing the MTU size > on all BGP speakers on the Internet at large? Before making such a > blanket statement, I would like to hear from vendors and operators > about the impact of such a change. i am trying really hard to sort out what you are trying to say and have failed. bgp is not carried over udp, but rather tcp. this is not a change in the mtu, it is a change in the bgp pdu carried over tcp. as bgp is next hop only, no transitive change in mtu would be needed anyway. > 3.9 If a BGPsec design uses signed NLRIs, it need NOT handle multiple > NLRIs in a single UPDATE, given the impossibility of splitting a > signed message while preserving the signature. > > I'm not certain why this would be in a requirements document. Can > anyone explain how this directly relates to the security of BGP? IE, > what is the direct relationship between stating that packing is no > longer needed in BGP, and improving the security of BGP itself? note the 'need not.' it does not say 'must not'. the point is that, if there is a signature over the bundled nlri, that signature can not survive the next bgp peer, who will unpack the nlris due to their routing policy not sending the whole bundle to their next peer. i.e. imagine R0 sends a bundle to its customer R1, and R1 selects some, but not all, routes from R0 and others from elsewhere to send to its customer, R2. and, btw, actual experimantal measurement has shown that unpacking nlri does not increase things unacceptably, even on small routers. > 3.14 A BGPsec design MUST NOT require operators to reveal proprietary > data. This includes peering, customer, and provider relationships, an > ISP's internal infrastructure, etc. Though it is understood that some > data are revealed to the savvy seeker by BGP, traceroute, etc. today. > > What sense does it make to say the only system which may be deployed > is one that protects information already publicly available? This is a > non-requirement, and must not be included in the requirements list. this is an absolute from many operators. there is information and there is information. basic security info hiding theory says that you can not absolutely protect anything, you can just raise the cost of getting it. this is one of the reasons for the failure of the IRR, many operators, especially some of the largest, just don't want to publish their customer lists because of sales poaching. it is not theory, but has happened. i have had the sales department come to me and ask me to do the bgp and traceroute research to tell them customer lists of competitors because the ones they were after were not in the IRR (uu, sprint, ...). i told them to foad, and the ceo backed me. [ and note that backup paths are not very visible in bgp or traceroute ] > 4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally > determine that the UPDATE has traversed the AS path indicated in the > UPADTE. Note that this is more stringent than showing that the path > is merely not impossible. > > I've always thought requirements documents proposed a set of > requirements, rather than a set of end goals. This entire "bullet" > needs to be replaced with a realistic set of requirements concerning > what can, and cannot, be proven about an AS Path in BGP, and then what > we can actually require. the difference between requirements and goals is sufficiently subtle that you will have to write it up formally to get through to at least me. bottom line: when i recieve an update for prefix P with path D C B A, i want firm assurance that A passed P to B, B to C, C to D, and D to me. firm, verifiable, assurance. that some database says that *some* prefixes are allowed from A to B to C to D to me does not mean *all* are. there are vast differences in how different prefixes are handled by each hop on the route. think peer, provider, customer relationships. > What does "proving the AS Path the update has traversed," prove, > precisely? Does receiving an update through a specific path prove > traffic sent to that destination will traverse the path listed? no, see security section. locking down the data plane is the next high mountain. one at a time. of course if you have a solution which locks down both the control plane and the data plane, i *extremely eagerly* await your i-d. > Does receiving an update prove that all destinations listed are > reachable along the path listed? Does receiving an update prove that > every AS along that path has agreed to forward traffic transmitted to > the destination indicated? yes, agreed to. of course, we can not yet guarantee that they do not have an accidental packet-based acl en route, see security section on data plane vs control plane. [ i had this bug this last week, a packet acl in path. nasty. eagerly seeking prevention. send i-d. ] > 4.3 Replay of BGP UPDATE messages need not be completely prevented, > but a BGPsec design MUST provide a mechanism to control the window of > exposure to replay attacks. > > Again, this is an assumption which I completely and totally disagree > with. What is the window size allowed in terms of time? Is it minutes, > hours, days, weeks, months, or years? tunable, i hope. i am not much worried about my research prefixes being replayed. root name servers may be. > In short, this document does NOT accurately reflect the needs or > requirements of BGP security, and should NOT be adopted as a WG > document. opinions may differ. you and steve kent had your time in a wg which went nowhere for years. let's try not to repeat old arguments and let's move forward. thanks. i will be in your area 8-12 feb. glad to chat face to face. randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
