On 2014-05-12 15:42, George, Wes wrote:
I see a thread dated 2013 Nov in GROW, in which substantive
discussion and
comments were provided after -03 was published, in which the authors
mainly just expressed why they were frustrated with SIDR and the IETF
in
general for in their minds, ignoring this problem because it was
hard,
rather than addressing the concerns raised within the WG. -04 is a
keepalive to reset the expiration date with no substantive updates.
Why
are we now talking about WGLC?
Because we'd like this memorialized in an Informational RFC, that's the
purpose, methinks.
Chris, you were one of the ones who said that your comments hadn’t
been
addressed yet.
(https://mailarchive.ietf.org/arch/msg/grow/0ho_RU3e15TCvp4p8ScCeObk42Y)
Eric owns comments follow-up, I'll defer to him on responding to that
bit....
Substantive comments:
This document provides one example of a route leak causing a problem
that
BGPSec does not protect against, but still does not do much to
provide
guidance on how such a leak would be systematically identified,
Nor does it have to in any programmatic way, IMO. It's easy for an
entry level routing person to understand what the problem is here, hell,
they have to deal with them every day. It doesn't have to expand to
every possible reason or define detection mechanisms. We hope folks
that read such things will be as clever as the SIDR folks and solve this
solution :-)
However, if you can be more specific about examples not covered or send
text then we'd be happy to incorporate it.
It does
note that there are data supporting the assertion that this is a real
problem, and imply that perhaps additional analysis of that data
would
reveal more information. I don’t think that anyone would dispute that
this
is a valid attack. However:
"This document is meant to provide input into routing
protocol design
choices being
considered within the IETF, and to foster discussion of the
practical
implications of "policy" and "intent" in operational routing
system
security."
This document provides no actionable guidance beyond articulating the
basics of the attack, certainly no meaningful discussion of policy vs
intent other than to note that discerning intent is difficult, and as
such
the draft is absolutely not ready for publication if the above is its
goal.
We didn't say we'd proclaim all is accomplished, we said we'd like to
foster discussions of policy v. intent. This very discussion makes me
think it works, and given that even you don't think anyone would dispute
that this is a valid attack, I claim success and request publication --
although perhaps we should update with more recent leak references and
we can certainly encourage more folks to do research, with a stable
reference, which was precisely the intent.
We’re not hiding behind SIDR’s carefully crafted requirements and
charter here, so let’s actually have the discussion about policy and
intent and see if we can come to some consensus on how to use that
info to
define a route leak such that we can first systematically find, and
then
protect against it.
I'm glad you agree it was carefully crafted. This draft is only meant
to document the issue above, which you seem to agree that no one would
dispute. It doesn't need to be the kitchen sink for attack vectors.
I absolutely want to see a solution to this problem,
but one example/existence proof isn’t enough to get us moving in that
direction.
I don't think that's a surprise Wes. We should document what some
believe the problems are before we begin designing solutions, else we'll
end up with more complicated solutions that don't address what me
operators believe to be the key issues.
-danny
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
