The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)
RFC 6720
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Stewart Bryant; former steering group member) Yes
(Barry Leiba; former steering group member) No Objection
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- 2.1 -- The G flag is meaningful only if the T flag is set to 0 (which must be the case for Basic Discovery), otherwise, the value of G flag SHOULD be ignored on receipt. What happens if it isn't? SHOULD means, basically, MUST unless you fully understand the consequences... so what are the consequences, so that an implementor might have a chance to understand them? ======== Other comments; no need to respond to these. Take them or modify them as you please: -- 1 -- Therefore, GTSM can fully benefit LDP protocol peering session established using Basic Discovery. I don't understand this sentence; maybe there's a word missing. But it also seems awkward. Does it mean this?: NEW Therefore, GTSM can provide full benefit to an LDP protocol peering session that was established using Basic Discovery. That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default without any configuration. But you just said that RFC 5082 said not to do that. I understand what you're getting at, so maybe this will make it clear?: NEW That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default without any configuration, while retaining the spirit of the advice in RFC 5082.
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
(Stephen Farrell; former steering group member) No Objection
(1) 5082 has a MUST for authentication if negotiating GSTM. I don't get why this "built-in" negotiation, which seems to me to be added post-facto, gets around this need for strong authentication. I'm not going to insist that you define such authentication, (be nice if someone did though), but I do think you need to say you're not adhering to the MUST from 5082. (2) When receiving an LDP Link Hello with G=1, what checks are to be made on the TTL for that packet? If you don't enforce GSTM on that, then presumably attacks could be mounted with a Link Hello that has G=0, defeating the negotiation (hence point (1) above I guess;-). Why is this ok? If you're really taking a "leap of faith" here, then that's probably fine, but should be stated IMO. In any case I think you need to be clear about whether the TTL on this packet needs checking or not. nits: - typo in section 3? "(i.e.,g G=1)" - s/g//? - typo in section 5: s/may cause LDP peering session/may cause an LDP peering session/
(Wesley Eddy; former steering group member) No Objection