[Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)

Mirja Kühlewind via Datatracker <noreply@ietf.org> Thu, 02 May 2019 11:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E76001200B9; Thu, 2 May 2019 04:24:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-data-channel@ietf.org, Roman Danyliw <rdd@cert.org>, dots-chairs@ietf.org, rdd@cert.org, dots@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <155679628494.24951.9145538661531263463.idtracker@ietfa.amsl.com>
Date: Thu, 02 May 2019 04:24:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/tHXJiVCDPYvGCG33PakNa5gQKIw>
Subject: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2019 11:24:45 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dots-data-channel-28: Discuss

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:


I support Suresh's discuss that the process of how it is indicated if a 1 or 2
byte mask is used is not clear. However, I would additionally like to discuss
why this bit mask is needed at all. The TCP flags field in RFC8519 is already
defined as bits. Storing these bits in a signal 8 bit field and applying a
matching operation is implementation specific only and doesn't require any
changes to the YANG model.

I would also quickly like to discuss the use of keep-alives as described in
Section 3.1: "While the communication to the DOTS server is
   quiescent, the DOTS client MAY probe the server to ensure it has
   maintained cryptographic state.  Such probes can also keep alive
   firewall and/or NAT bindings.  A TLS heartbeat [RFC6520] verifies
   that the DOTS server still has TLS state by returning a TLS message."
I understood that multiple requests can and should be send in the same
connection, however, I would expect that those requests are send basically
right after each other, such as a look-up and then change of the config. I
don't see a need to keep up the connection for a long time otherwise.
Especially any action performed are (other than in the signal channel case) not
time critical. Therefore I would rather recommend to close and reopen
connections and not recommend to use keep-alives at all.


Editorial comment: As alias and migration-scope (in the signal channel
document) have the same fields, wouldn't it make sense to only definite it once