RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)
RFC 7551
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
The term "reverse unidirectional LSPs" breaks my head as you really mean something like bi-directional bundled LSPs. But anyhow, that might be just me.
(Pete Resnick; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
I don't have any specific threat to offer, but I have to say this sets my antennae jangling a bit from a security perspective. If you let someone loose on an ingress node here who could setup these bidirectional associations, I'd imagine they could generate fun and profit, would that be fair? Has anyone tried to play the attacker/red-team here to see if they can find any issues with this? Could I probe from the ingress node and figure out what other LSPs exist at an egress node, and they try take those over? As another nit, I see we say here "introduce no additional" but see RFC6780, which says "no new security considerations are introduced" and "there are no new risks" and we all point back to RFC5920. (Sorry for the whine, that "nothing new here" thing grates when one sees it so often;-) I guess I basically wish I shared your confidence. And while I don't, I also don't know enough about MPLS to point out anything that'd justify trying to block this.
(Ted Lemon; former steering group member) No Objection