>>> 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.
and once again, the nlri packing issue is not about performance at all.
it is about security, security, and security. please actually read the
prior email.
>>> 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.
not a problem. you don't have to.
>>> 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.
did that two emails ago.
>>> 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.
yep. that is the infosec model. read previous email.
>>> 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?
no i am not. read the paragraph you just quoted above.
>>> 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.
that bgp only advertises best path is in rfc 4271. apologies that it is
not a reference in the draft. we'll fix that in the next draft.
>> "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.
if the abstract does not make this clear enough, please suggest wording.
This document describes requirements for a future BGP security
protocol design to provide cryptographic assurance that the origin AS
had the right to announce the prefix and to provide assurance of the
AS Path of the announcement.
>>> 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.
not in the ascii. perhaps in the ebcdic translation.
>>> 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?
no.
>> actually, the document does. it is the conversation which has drifted a
>> bit
>
> No, the document explains a solution, not requirements.
that is an assertion which is a bit hard to substantiate.
> 1. There is no list of information operators expect to be hidden.
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.
> 2. There is no idea of an acceptable performance degradation.
nope. do you have a suggestion?
> 3. There is no statement of what is you're actually trying to achieve.
funny, most folk find the abstract and intro pretty clear on that. but
if you have more complete wording, do send text.
>>>> 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.
i am not sure these are the only ways to do so. but this is pretty
irrelevant as the draft pretty clearly says
3.4 A BGPsec design need not prevent attacks on data plane traffic.
It need not assure that the data plane even follows the control
plane.
so what exactly is your point here?
>> how about something like "formally determine that the UPDATE has
>> traversed the AS path indicated in the UPADTE?"
>
> How about explaining what this proves?
i have tried. sorry if it does not make it clear to you.
> When you are going the wrong way, the most constructive step you can
> take is to turn around.
good advice.
bye.
randy
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
