Did you really mean to sign the next-hop? it seems infeasible...
The constant answer to any challenges to the requirements documents is:
"We are simply protecting BGP semantics with signatures."
1. Signing a semantic doesn't make it secure.
2. If you're going to claim you're all about protecting BGP semantics,
then protect all of them, not just one.
Also, LocalPref is a locally used/determined/created (non-transitive)
item, adding that set of bits into the signature seems blatantly
wrong, since the data won't exist when you pass the route outside your
ASN the verification is going to fail, for every route you send (which
had a localpref != default), That CERTAINLY seems like something you
would want to avoid, right?
So what you are saying is that you don't want to protect attributes that
aren't carried more than one hop through the internetwork --I.e., next
hop is only carried between one set of (presumably) locally connected
eBGP peers, so it shouldn't be protected. This leaves us with two problems.
==
1. Since many other attributes carried in this fashion actually impact
the usability or trustworthiness of a route, what justification can you
give for not protecting them? Because it's "too hard?"
2. You say:
AS1--AS2--AS3
AS1 shouldn't care about what goes on between AS2 and AS3. But wait...
Then why should AS1 care about the AS Path interactions between AS2 and
AS3, precisely? How can AS1 really trust that traffic it sends to AS2
will actually be forwarded through AS3 if next-hop games are going on
between AS2 and AS3? Or local pref games are going on within AS2? Or AS3
is sending AS2 some community that AS2 is locally interpreting in some
way that would impact AS1's decision about forwarding along that path?
The reality is that local decisions impact the global reliability of
each piece of routing information.
==
I would posit all this confusion comes from simply not doing a good job
of defining the problem in the first place. A solution was chosen first,
and then a problem set found that this specific solution could "solve"
(and no other!), regardless of the secondary problems and complexity the
chosen solution might happen to bring to the table.
Which is why I oppose adoption of this draft as a WG document.
:-)
Russ
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
