Re: [Teas] Roman Danyliw's No Objection on draft-ietf-teas-gmpls-signaling-smp-11: (with COMMENT)

[Jeong-dong Ryoo <[e-mail]>]

Hi, Roman.


Thank you for your review and comments. 

The co-authors of this draft will revise the draft as you suggested. 

Regarding a registry for LSP (Protection Type) Flag;
According to RFC 4872, only one value SHOULD be set at a time for the 6-bit LSP (Protection Type) Flags. 5 bits have already been defined in RFC 4872, and one remaining bit is being used by this draft. Therefore, without relaxing the “one value at a time” restriction in RFC 4872 and confirming such a change doesn’t impact any existing implementations adversely, it doesn't seem possible to define any more types in the future. Therefore, we would like to keep it as is now.

Regarding Section 8, the text means that network operators shouldn't leak information about routes and priorities of LSPs that they use to protect traffic. As you questioned, we also think the current text is asking for something too strong without suggesting a way to do it. We will modify the text as follows:
   For this reason, it is important not only to use security  
   mechanisms as discussed in [RFC4872] but also to acknowledge that 
   detailed knowledge of a network's topology, including routes and priorities of LSPs, 
   can help an attacker better target or improve the efficacy of an attack.


Best regards,

Jeong-dong (on behalf of the co-authors)




-----Original Message-----
From:  "Roman Danyliw via Datatracker" <[e-mail]>
To:     "The IESG" <[e-mail]>; 
Cc:      <[e-mail]>;   <[e-mail]>;   <[e-mail]>;   <[e-mail]>;   <[e-mail]>; 
Sent:  2022-04-07 (목) 03:19:41 (UTC+09:00)
Subject: Roman Danyliw's No Objection on draft-ietf-teas-gmpls-signaling-smp-11: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-teas-gmpls-signaling-smp-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-gmpls-signaling-smp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to David Mandelberg for the SECDIR review.

** Section 6.3

   In order to indicate the SMP preemption priority, the 16-bit Reserved
   field [RFC4873] of the PROTECTION object is redefined.  The last 32
   bits in the PROTECTION object defined in [RFC4873] are updated as
   follows:

I had trouble following the references in the above text to understand what
exactly was being updated.  John Scudder help me understand the follow:

RFC 4872 reserved a 32-bit field in the PROTECTION object header. Subsequently,
RFC 4873 allocated several fields from that field, and left the remainder of
the bits reserved. This specification further allocates the preemption priority
field from those formerly-reserved bits.

I’d recommend included text to this effect.

** Concur with Paul and Francesca that a registry for LSP (Protection Type)
Flag would be helpful.

** Section 8.

For this reason, it is important not only to use security
   mechanisms as discussed in [RFC4872] but also to preserve privacy of
   information about protecting LSPs within the network.

How would one "preserve the privacy of information about protecting LSPs"?  Is
this equivalent to acknowledging that detailed knowledge of a network's
topology can help an attacker better target or improve the efficacy of an
attack?