>> 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.
Once again, the requirement should be for no more than "x%" performance hit, not specific implementation points. >> 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. Sorry, I don't buy 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? Everything. Again, a list, with use cases to back the list up. >> 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 And somehow you expect making people work for it will make it more secure. >> 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 :). So you're saying that backup paths should be able to be hidden until they are actually used? Can you put together a list of the specific information you think needs to be hidden, and back it up with use cases? >> 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. So then list this as a requirement. It's something that many different options can provide for, of course, not just S-BGP. > "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? No, we cannot. BGP announces _something_. Are you trying to secure the something, or are you trying to secure the announcements? These are two completely different problems. >> 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." You said so in your email. >> 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. So you are stating that what you are trying to add is that A can validate the policy between B and C? > actually, the document does. it is the conversation which has drifted a > bit No, the document explains a solution, not requirements. 1. There is no list of information operators expect to be hidden. 2. There is no idea of an acceptable performance degradation. 3. There is no statement of what is you're actually trying to achieve. >>> no, see security section. locking down the data plane is the next high >>> mountain. one at a time. To "lock down the data plane," there are only two options: 1. Circuit switching. 2. End to end encryption, which is outside the scope of BGP or any other routing protocol. > how about something like "formally determine that the UPDATE has > traversed the AS path indicated in the UPADTE?" How about explaining what this proves? >> 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. Exactly. So, again, what are you proving by showing what the policy between two peers multiple hops away is? >> 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. Actually, it is quite true. Simply put, BGP doesn't contain the information about more than connected policy; you can't secure information you don't have. Further, as long as I can underclaim, or aggregate legally to bury a prefix I don't want you to know about, you can't prove anything about the path beyond the next immediate hop. So, which is it --you can, or cannot validate anything beyond the next hop? >> 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? Because that's not what the doc says. It says "replays are acceptable." Again, put a number in there. > 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. When you are going the wrong way, the most constructive step you can take is to turn around. But this isn't about your modifications to S-BGP. You might have noticed I've not mentioned any specific protocol modification _once_. This is about a requirements document that is, essentially, specifying a protocol, rather than specifying requirements. If you want to go down a road, then let's figure out where it is we want to go, rather than just plowing ahead on any random road, and hoping we get someplace useful. Russ
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
