Subject: [bess] Roman Danyliw's No Objection on draft-ietf-bess-srv6-services-10: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 15 Feb 2022 19:17:05 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-bess-srv6-services-10: 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/blog/handling-iesg-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-bess-srv6-services/

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

Thank you to Joseph Salowey for the SECDIR review.

Thank you to the authors for the implementation report pointer
(draft-matsushima-spring-srv6-deployment-status)

I support Alvaro Retana’s DISCUSS position.

I also support Warren Kumari’s DISCUSS position.  In particular, discussing the
magnitude of the exposure of an internal topology due to a BGP leak would be
helpful to document.

** Section 8.  It would be worth repeating the two key security assumptions
from RFC8402:

OLD
SRv6 operates within a trusted SR domain with filtering of traffic at
   the domain boundaries.

NEW
SRv6 operates within a trusted SR domain with filtering of traffic at the
domain boundaries. Likewise, there is an assumed trust model such that any node
adding an SRH to the packet is assumed to be allowed to do so.

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 16 Feb 2022 17:03:36 +0530

Hi Roman,

Thanks for your review. Please check inline for a response to your proposed
text change.

> https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/
KT> I agree. I think it would be good to also qualify the newly inserted
sentence with the option of using the SRH HMAC TLV (where verification is
required) that was introduced by RFC8754.

Thanks,
Ketan