Subject: [tsvwg] Stephen Farrell's No Objection on draft-ietf-tsvwg-circuit-breaker-13: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 16 Mar 2016 17:24:36 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-tsvwg-circuit-breaker-13: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/

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

- I agree with Ben's discuss.

- Do the MPLS folks and similar agree with 6.1? If so, great.
(And how did you figure that out?) If not, doesn't that make a
big part of this BCP mythical?  (Which would seem
undesirable.)

- 6.2, 2nd para: what question?

- Section 7 (and earlier): You RECOMMEND a crypto mechanism to
mitigate possible DoS. In both cases however, the statement is
ambiguous. Are you RECOMMENDing a mechanism be defined or that
one be used? (And of course if you asked me, I'd say that it'd
be better to a crypto mechanism MUST be used, even when
off-path attacks seem unlikely to work.)

---

From: [email-masked]
Date: Thu, 17 Mar 2016 08:42:43 -0000

Please see below, with a rather long plea to discuss better text.

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-circuit-breaker/
- I agree not so readable. I propose this:
OLD:
"Even
   when all transports sharing a tunnel individually reduce their
   transmission rate when network congestion is detected, the answer to
   the question is not always obvious.  The overall traffic formed by an
   aggregate of flows that implement a congestion control mechanism does
   not necessarily prevent persistent congestion.  "
NEW:
  "However, even if the individual flows sharing a tunnel each implement a
congestion control mechanism, and individually reduce their transmission
rate when network congestion is detected, the overall traffic resulting
from the aggregate of the flows does not necessarilly avoid persistent
congestion. "

> off-path attacks seem unlikely to work.)

The intention is to recommend *using* a crypto mechanism.

You come from a slightly different perspective, and I'd be happy to
consider some refactoring to get the security recommendations correct. My
first proposal to rework the text to bring the issues out slightly more
clearly is:

"The authenticity of the source and integrity of the control messages
(measurements and triggers) MUST be protected from off-path attacks.
Without protection, it could be trivial for an attacker to inject fake or
modified control/measurement messages (e.g., indicating high packet loss
rates) causing a Circuit Breaker to trigger and to therefore mount a DoS
attack that disrupts a flow.

Simple protection can be provided by using a randomized source port, or
equivalent field in the packet header (such as the RTP SSRC value and the
RTP sequence number) expected not to be known to an off-path attacker.
Stronger protection can be achieved using a secure authentication protocol
to mitigate this concern.

An attack on the control messages is relatively easy for an attacker  on
the control path when the messages are neither encrypted nor
authenticated. When there is a risk of on-path attack, use of a
cryptographic authentication mechanism for all control/measurement
messages is RECOMMENDED to mitigate this concern, and would alo provide
protection from off-path attacks.

There is a design trade-off between the cost of introducing cryptographic
security for control messages and the desire to protect control
communication. For some deployment scenarios the value of additional
protection from DoS attack will therefore lead to a requirement to
authenticate all control messages.

Transmission of network control messages consumes network capacity. This
control traffic needs to be considered in the design of a Circuit Breaker
and could potentially add to network congestion. If this traffic is sent
over a shared path, it is RECOMMENDED that this control traffic is
prioritized to reduce the probability of loss under congestion. Control
traffic also needs to be considered when provisioning a network that uses
a Circuit Breaker.
"

I shudder (personally) at the idea of writing a MUST encrypt statement in
a BCP that covers a wide raft of techniques and protocols. However I can
see real value in stating something more as a check-list item to point new
protocol designers to act upon.

--- Perhaps we could add something like "An IETF specification for a
circuit breaker mechanism is expected to describe how it protects the
control mechanism and to specify appropriate security mechanisms to
authenticate and protect the control messages"

... would such a requirement "to specify " *(or some better text) include
a MUST?

Gorry