Skip to main content

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