>> 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.
I understand the reasoning, but I'm not certain why this should be addressed as a "requirement." I could see something saying, "any proposed system should not decrease performance by x%," let people discuss what x should be. To say that a specific mechanism that will impact performance is acceptable as a "requirement," no matter what the impact is, because the authors are convinced that it "won't hurt anything," is presuming on the entire set of possible environments, and putting the requirement in a "backwards" way. Some other system may decrease performance in a different way, but the WG is not open to discussing such tradeoffs the way this is currently written. >> 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. It's an absolute must that information already revealed publicly in one context not be revealed in another. Interesting... It would be better to have an actual list here. I've asked, for years, for specific instances --use cases-- where specific information should not be revealed. Thus far, the only ones I've actually been given are, "we don't want a peer to know we're breaking the contract we have with them." I don't find these sorts of reasons convincing. What a requirements document should have, it seems to me, is a list of information that the operator community has determined cannot be revealed and a reason for each one. > [ and note that backup paths are not very visible in bgp or traceroute ] Okay, so you're suggesting two things: 1. The list of the AS' a given AS is peered to should not be collated into a conveniently available list. You expect people to be forced to work for this information. 2. Backup connections should not be advertised unless they are used. In other words, only connections through which prefixes are actually being advertised should be collectable from the system at large. > 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. The question that needs to be answered here is simple: Are you trying to have verifiable proof for a court case, or are you trying to validate that the destination given actually exists through the advertising peer to the extent possible within the protocol itself. To say that one thing is "more assured," than another is to assume the answer to the question, "more assured in what terms?" > 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. First, you're assuming that in this network: A--B--C A can verify the policy between B and C somehow for a specific prefix or reachable destination. BGP simply isn't built this way. Second, you're assuming that the only way to verify things on a per prefix basis is by signing the updates. Making assumptions about a given solution set within a requirements document is a "bad thing." Don't do it. Explain the requirements, not the solution. >> 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. You've not explained what you mean when you say you want to "lock down" the control plane. Again, what are you trying to prove? That an update passed along a certain path? Does that provide you with policy assurance? Does it prove the destination indicated exists and is reachable along the path indicated? Does it prove packets transmitted to the destination will follow this path? Or, again, are you mostly interested in proving what a peer sent to you for contract enforcement? These are all legitimate concerns, but you need to indicate which one you're actually trying to address. > 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. It's called circuit switching, rather than packet switching. >> 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 Um, no it doesn't. Simply receiving an update does not prove it is "within policy" for the receiver to send traffic along the path specified to the destination specified. In fact, you can't prove this unless you expose the peering pairwise policy of every connected pair of AS' in the path. And you can't prove it unless you remove aggregation from the routing system. >> 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. This isn't a requirement. Put a number in there, so we can discuss it. > i will be in your area 8-12 feb. glad to chat face to face. I'm in RTP, not SJ. :-) Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
