Skip to main content

The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-gtsm-09

Yes

(Adrian Farrel)
(Stewart Bryant)

No Objection

(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Wesley Eddy)

Note: This ballot was opened for revision 07 and is now closed.

Adrian Farrel Former IESG member
Yes
Yes (for -07) Unknown

                            
Stewart Bryant Former IESG member
Yes
Yes (for -08) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2012-06-05 for -08) Unknown
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 IESG member
No Objection
No Objection (for -08) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2012-06-05 for -08) Unknown
(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 IESG member
No Objection
No Objection (for -08) Unknown