hi russ, >>> 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."
once again, note the 'need not.' it relaxing the nlri packing requirement. as such, it is probably wise to be in a requirements statement, but is not itself a new requirement. if pdus/attributes are signed (not a given), a signed pdu with multiple nlris cannot be split into separate pdus. since splitting is normal -- due to local policy or perhaps better routing advertisements for that prefix but not others in the pdu -- it follows that a bgpsec speaker cannot accept any advertisement where a signature covers more than one prefix. otherwise, it will become something such as, "a bgpsec receiver who gets a message with a single signature over multiple nlris may have to discard the signature if routing policy will separate the nlri before sending them onward." and i suspect that both you and i might find this too prescriptive and detailed. > 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. relaxing nlri packing is not a performance issue. it is that s-bgp was broken in that it thought it could sign a packed pdu which had multiple nlris, not thinking through that the next router would break apart the nlris under local policy and thus break any aggregated signature. > 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. red herring. this is not about performance at all, but about security. >>> 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... and common in the infosec world. as an infosec geek just said to me, saying it in another context can prove (in a loose sense, i presume) that something is true. see (for an otherwise appalling example) the us military on wikileaks. > 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. i have not heard that quote. amusing stalking horse. excuse if i ignore it. > 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. sorry. what was unclear about "This includes peering, customer, and provider relationships, an ISP's internal infrastructure, etc.?" it's not our problem or prerogative; operators, who will choose to deploy or not, have made their requirement clear. is it really our prerogative to tell the operators what and how they have to justify to us? >> [ 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. indeed > 2. Backup connections should not be advertised unless they are used. nope. i did not say that. i said that backup paths are usualy not visible in analyses of public routing data. this is due to bgp's best path choices not propagating the less-preffered paths, and preserves today's properties. bgp is one of the world's best information hiding protocols :). paths that are actually used are disclosed to the parties on that path and to those to whom their policy *chooses* to leak the path. operators like this. otoh, researchers trying to generate AS topology graphs from public data hate this (see our paper in submission, http://archive.psg.com/101216.TenLessons.pdf). of course, the origin of a backup path is the same as that of a primary, and likely the more widely propagated, path. so the roa is the same. > In other words, only connections through which prefixes are actually > being advertised should be collectable from the system at large. not should be. are. see endless research papers on bgp analyses based on route views and ris. >> 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. "destination exists through the advertising peer" is a new and novel phrasing. i can see why it would be confusing. it sure confuses me, which i admit is a low bar. can we stick to bgp annoucements, please? > To say that one thing is "more assured," than another is to assume the > answer to the question, "more assured in what terms?" sorry, i missed where i said "more assured." >> 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. no. current bgp is not built this way. if it was, we would not need to discuss bgp-level security. as to per-prefix verifiability, you may want to look at what steve kent's s-bgp proposals were trying to achieve. though operationally broken, they were very much per-prefix. > 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. actually, the document does. it is the conversation which has drifted a bit 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. >>> 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. how about something like "formally determine that the UPDATE has traversed the AS path indicated in the UPADTE?" >> 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. so we can move on and consider this a red herring for the nonce. >>> 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. one does not send traffic along a path. one sends it to a next hop. and R0 receiving a bgp announcement of prefix P from R1 does indeed state that it is "within policy" for R0 to send data toward P to R1. > 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. actually, this is quite untrue. this is still stuck in the peering database model. the hope is that BGPsec does not need to 'expose' anyone's policies any more than bgp announcements do now. folk may choose to inject aggregated prefixes *into* the routing system, and we encourage them to do so. but there is effectively no aggregation *within* the inter-provider routing system. see the actual measurements discussed on nanog etc. >>> 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. what is not clear about o needs vary, and o it should be tunable? just for example, for my research prefixes, i am not much worried about replay attacks, and would be happy with O(days). i imagine root name servers might s/days/hours/ but really should not speak for them. >> i will be in your area 8-12 feb. glad to chat face to face. > I'm in RTP, not SJ. well, i am usually in tokyo, so do call when you come by and i can wander over to the dreaded rappongi where the cisco offices are. but, this week, i am in sjc playing operator and architect working with vendors on this very subject. sorry we could not get together. email is not the best communication medium. we now have route origin validation pretty much nailed down, the documents are leaving sidr for the iesg, adn we have running code in routers. imiho, it would be really good to not go around these old overly well-traveled negative circles and to finally move bgp as-path security forward. constructive work from you and others would be a real step. thanks. randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
