RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)
draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07
Yes
(Adrian Farrel)
No Objection
(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Kathleen Moriarty)
(Pete Resnick)
(Spencer Dawkins)
(Ted Lemon)
Note: This ballot was opened for revision 07 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
()
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
()
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
()
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
()
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2015-03-11)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-03-11)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown