On Fri, 8 Jul 2011, Robert Raszuk wrote:
On the previous post I just wanted to limit such bgpsec less exchange to stub
customers only. But I agree and stand corrected that if we solve it for all -
transit included - then there is no need to make any special treatment for
stubs. Question withdrawn.
---
However I would like to ask for some clarification on why bgpsec is all about
securing advertised nets and does not (at least to the best of my knowledge)
certify that such prefixes have been advertised with legitimate next hops
(the one which the prefix owner really owns). I browsed the respective drafts
and did not find a trace of such.
The owner of the advertised prefix doesn't have ownership of the next hops
along the path. nor does it have anything to say about the legitimacy of
next hops along the path.
There's this whole "third part next hop" concept which would make
determining legitimacy of the next hop complicated.
--Sandy, speaking as regular ol' wg member
If we talk about RS in particular such RS is not in the data path hence it is
not modifying next hops as received from his clients.
How are we going to protect the paths from compromised RS where the prefixes
are advertised correctly but next hops are bogus ? What's worse client's
customers connected via such RS may have chosen such paths as best even if
they have alternatives ...
Thx,
R.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
