Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context
RFC 7246
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Adrian Farrel; former steering group member) Yes
The last paragraph of Section 1 begins: In order to use the mLDP in-band signaling procedures... ...but "the mLDP in-band signaling" is a new term. It turns out that it meas exactly what the previous paragraph ended up saying, viz. encoded into the mLDP FEC element. So I suggest that you update the end of the previous paragraph to read encoded into the mLDP FEC element in what this document terms "mLDP in-band signaling."
(Stewart Bryant; former steering group member) Yes
(Barry Leiba; former steering group member) No Objection
No objection, and no complaint at all here... just an observation: I find it interesting that an 11-page document has six authors.
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) (was Discuss) No Objection
Thanks for the discussion on the handling of scoped IPV6 scoped multicast addresses. Moved to a COMMENT for historical reasons... I have a general concern, but I am not sure if it is the fault of this document, RFC 6513, or RFC 6826 so let's discuss it here for the time being... How are non-global-scoped IPv6 multicast addresses handled? There is no discussion in this document about verifying that the creation of an MDT is not violating a scope boundary. RFC 4007 (section 10) is very clear on the rules that must be followed when creating forwarding state. If these rules are not followed, scoped packets can leak out of their allowed zone creating a vulnerability. Notionally, I would have expected to see something in Section 2 saying that scopes need to be checked as a part of the signaling procedure. There does not appear to be any discussion of scoped addresses in 6513, 6512, or 6826. Where in the MPLS VPN specs is support for scoped multicast addresses defined?
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
It seems kind of incredible that the security considerations here are so simple, when we're glueing together two different ways to do multicast. Surely at least the security considerations relevant to PIM ought be noted? Would it (un)fair of me to guess that perhaps nobody has really looked for potential new vulnerabilities here? As it happens, I don't have the time before the telechat, nor probably the MC clue, to help with that so this is not a DISCUSS, but you could set my mind at rest if you told me that yes, a bunch of folks with that clue and some security clue have really spent time looking at this.
(Ted Lemon; former steering group member) No Objection