On 2014-05-14 07:58, Jeffrey Haas wrote:
This to a large extent identifies the problem: BGP *as a protocol*
has no
idea what these boundaries are. Thus, "intent" is up to the
perception of
the involved parties.
Ans therefore, the solve need not necessarily be IN BGP itself.
This thread has looped a few iterations with "this is a problem!" and
SIDR
basically saying "there's nothing in BGP here to secure". Both
things are
still true.
Heh, perhaps.
I think documenting route-leaks and their potential negative (or
malicious)
consequences is worth GROW doing.
Concur, especially since it's a global routing operations related issue
that happens all the time, and persists whether BGPSEC is deployed fully
or not.
I think this issue exists even without bgpsec being involved. While
it's
correct that bgpsec doesn't add anything here, until the underlying
base
protocol has some idea of what we can do, picking on bgpsec doesn't
help.
If anything, I'd probably take the route-leak document and say
"here's the
problem" with a one or two sentence note that bgpsec doesn't do much.
I don't agree, and I don't believe this problem needs to be solved IN
BGP. And I do believe it's extremely important to provide a stable
reference to these attacks in order for folks to realize it doesn't
solve this very basic problem.
In it's current form, I don't think the document is ready to
progress.
What specifically would you change in the document, given that it's
intent is to highlight how BGPSEC does not address the route leak issue,
and that it's a real operational issue that at least the authors are
concerned with?
I'd even suggest it needs to be rescoped.
If folks are interested in doing work more broadly than this then
they're certainly welcome to. If they're not interested in doing the
work then it's disingenuous to suggest it be rescoped as such,
particularly at this stage.
The interesting work is resurrecting the thread on injecting routing
policy
intent into some system we can secure. :-)
I suppose degrees of "interesting" is a matter of perspective, and the
notion of strict linear thinking that suggests "injecting" it into the
active routing system is the only way to solve the problem is perhaps
why we keep dancing around this (and other adjacent topics such as
anti-spoofing in the datapath). Quite frankly, I prefer inter-domain
static routing or SDN over what I see BGPSEC-enabled RPKI bringing to
the table - and I seriously mean that -- and they might well beat
BGPSEC off the launchpad :-)
-danny
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
