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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Wed, 08 May 2019 07:30 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF46912008F; Wed, 8 May 2019 00:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YKWlj3pNqxK; Wed, 8 May 2019 00:30:38 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C586120041; Wed, 8 May 2019 00:30:37 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1557300233; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=BcqDgF6kSH5BNhWhlSBJRKgf1E7NI/RhglaLSO acgfQ=; b=KRhMjO5StWjvJNSdhiSIfJnHqxyWm7sKecMcr4nb zJ87TX4mN5BtfmT73ymCMTVI1F5Fd6gQ89wDSZxJZ+wyDC8iaB tp8l47XizCkOO6nXNhYYauSvB8q2ulzNqyzbC4fer0j+WyKRVi IulQ0KvGlk8SE2kgDNAEtANg2L5hj7I=
Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1776_2e83_c6b4307c_9aa8_409c_8397_a99ac0f76608; Wed, 08 May 2019 01:23:52 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 May 2019 01:30:28 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 8 May 2019 01:30:28 -0600
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 May 2019 01:30:27 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2776.namprd16.prod.outlook.com (20.178.233.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Wed, 8 May 2019 07:30:24 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::8921:8f4d:4710:4379%2]) with mapi id 15.20.1856.012; Wed, 8 May 2019 07:30:24 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: "draft-ietf-dots-signal-channel@ietf.org" <draft-ietf-dots-signal-channel@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: =?utf-8?B?W0RvdHNdICBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1p?= =?utf-8?B?ZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMzE6ICh3aXRoIERJU0NVU1MgYW5k?= =?utf-8?Q?_COMMENT)?=
Thread-Index: AQHVAM4JdK3c8pci6021tTnw22KeZaZeJDAAgAAhFQCAAR7qIIAAfbSAgAD2T8A=
Date: Wed, 8 May 2019 07:30:24 +0000
Message-ID: <BYAPR16MB2790DB3F702C9354E68071F9EA320@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <155672175129.924.6789867477696592350.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA68C1A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <F5FA219E-0124-43D8-A3FE-EAEDDAB7CA22@kuehlewind.net> <20190506155033.GE19509@kduck.mit.edu> <BYAPR16MB2790783166891132BDA97CB0EA310@BYAPR16MB2790.namprd16.prod.outlook.com> <20190507162721.GH19509@kduck.mit.edu>
In-Reply-To: <20190507162721.GH19509@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0077b9f0-067e-438b-330a-08d6d387093c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2776;
x-ms-traffictypediagnostic: BYAPR16MB2776:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <BYAPR16MB27760A854F9B324AF3399856EA320@BYAPR16MB2776.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(346002)(39860400002)(396003)(32952001)(189003)(199004)(13464003)(71190400001)(71200400001)(81166006)(81156014)(7736002)(30864003)(316002)(8936002)(86362001)(3846002)(14454004)(52536014)(54906003)(99286004)(7696005)(476003)(966005)(229853002)(5024004)(6436002)(14444005)(256004)(66066001)(74316002)(6916009)(486006)(305945005)(55016002)(224303003)(2906002)(80792005)(76176011)(72206003)(53946003)(53936002)(446003)(6246003)(66574012)(478600001)(4326008)(68736007)(66556008)(186003)(66476007)(5660300002)(6116002)(25786009)(64756008)(66446008)(66946007)(33656002)(11346002)(76116006)(73956011)(6306002)(53546011)(26005)(102836004)(2171002)(6506007)(9686003)(85282002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2776; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 6sbfsjzp1Y9T+kF2XiCYnIXFkaMkVkuJqyl3dQGIilCovumdlxH/0TWe9FatNm0tGhxf9Dop9H03tkXm9zk7aQtpjZY2Rv0E905Drn+jRLNwE6MZP95qqb3MSuGOzGUzt77CdpZrmvcO6kP9I8s1pnpJYVxJFZ8aTo5vqp0yWKi/G38wAdVl7rxi8T/4Lxqwqn1dpVeoRoaCaz2B6micnFpc2MwypyAZEZjRat+VAvgoS/EoTWIqEoG9f4p69REUNKXymLarL9u8grS91i0xbEW1oeXzqNsKnCqEyBSObLRJ+wWxvWv20AM3AHk4BRtqrJmfz6GcTi++AR39N34YS213JyucXJpWWZl7e9CzYAIVUoGlTcwkUs/VBol/yheyAcWeiq/dwnvEZiuNT0tuX0ZBlV7aPt1fDlYbvEiAEr4=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0077b9f0-067e-438b-330a-08d6d387093c
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 07:30:24.7188 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2776
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.1
X-NAI-Spam-Version: 2.3.0.9418 : core <6541> : inlines <7074> : streams <1820907> : uri <2841862>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/g40hLYKYvovCtEX1m2Gbkg5qs0s>
Subject: Re: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?dots-signal-channel-31=3A_=28with_DISCUSS_and_COMMENT=29?=
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 08 May 2019 07:30:42 -0000

> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: Tuesday, May 7, 2019 9:57 PM
> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> Cc: draft-ietf-dots-signal-channel@ietf.org; dots-chairs@ietf.org; Mirja
> Kuehlewind <ietf@kuehlewind.net>et>; dots@ietf.org; The IESG <iesg@ietf.org>
> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-signal-
> channel-31: (with DISCUSS and COMMENT)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> On Tue, May 07, 2019 at 10:47:50AM +0000, Konda, Tirumaleswar Reddy
> wrote:
> > Hi Ben,
> >
> > Please see inline
> >
> > > -----Original Message-----
> > > From: Dots <dots-bounces@ietf.org> On Behalf Of Benjamin Kaduk
> > > Sent: Monday, May 6, 2019 9:21 PM
> > > To: draft-ietf-dots-signal-channel@ietf.org
> > > Cc: dots-chairs@ietf.org; Mirja Kuehlewind <ietf@kuehlewind.net>et>;
> > > dots@ietf.org; The IESG <iesg@ietf.org>
> > > Subject: Re: [Dots] Mirja Kühlewind's Discuss on
> > > draft-ietf-dots-signal-
> > > channel-31: (with DISCUSS and COMMENT)
> > >
> > > This email originated from outside of the organization. Do not click
> > > links or open attachments unless you recognize the sender and know
> > > the content is safe.
> > >
> > > To add on to Mirja's discussion...
> > >
> > > On Mon, May 06, 2019 at 03:52:10PM +0200, Mirja Kuehlewind wrote:
> > > >
> > > > > On 2. May 2019, at 12:00, <mohamed.boucadair@orange.com>
> > > <mohamed.boucadair@orange.com> wrote:
> > > > >
> > > > >> -----Message d'origine-----
> > > > >> De : Mirja Kühlewind via Datatracker [mailto:noreply@ietf.org]
> > > > >> Envoyé : mercredi 1 mai 2019 16:43 À : The IESG Cc :
> > > > >> draft-ietf-dots-signal-channel@ietf.org; Liang Xia; dots-
> > > > >> chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org Objet :
> > > > >> Mirja Kühlewind's Discuss on draft-ietf-dots-signal-channel-31:
> > > > >> (with DISCUSS and COMMENT)
> > > > >>
> > > > >> ---------------------------------------------------------------
> > > > >> ----
> > > > >> ---
> > > > >> DISCUSS:
> > > > >> ---------------------------------------------------------------
> > > > >> ----
> > > > >> ---
> > > > >>
> > > > >> 1) Port usage (see section 3):
> > > > >> The port request for DOTS was reviewed by the port expert team.
> > > > >> Some members of the team were concerned about the assignment
> of
> > > > >> a separate port number for DOTS as Coap is used and already has
> > > > >> a designated port number. I believe that Coap is used as a
> > > > >> transport in the case and DOTS provides a separate service
> > > > >> compared to what Coap is usually used for, however, it is not
> > > > >> clear why DOTS needs a designated port. Section 3 says that the
> > > > >> port can either be preconfigured or dynamically detected,
> > > > >> therefore it is not clear why a fixed port is needed (see also
> > > > >> section 7.1. of RFC7605). In the port review process the
> > > > >> authored argued that a port is needed to differentiate the DOTS
> > > > >> service in the network. However, this is not an endorsed usage
> > > > >> for port numbers (see section 6.2. of RFC7605). Further, I
> > > > >> believe assigning a fixed port might actually add an attack
> > > > >> vector for DOTS, either by DDoSing the respective port at the
> > > > >> DOTS server, or any attempt to block DOTS traffic on the network
> from the DOTS client to the DOTS server.
> > > > >
> > > > > [Med] FWIW, below the reasons why we believe that a DOTS port is
> > > needed:
> > > >
> > > > I’ve read the communication with the experts. As I wrote in my
> > > > discuss
> > > point above, I agree with you that dots is a separate service and
> > > should not use the Coap port, however, I have a different question
> > > which is why do you need a dedicated fixed port? Please see further
> below.
> > > >
> > > > >
> > > > > ========
> > > > > (1)
> > > > >
> > > > > We are familiar with RFC7605. We confirm that the port we are
> > > > > asking for
> > > is:
> > > > >
> > > > >   o  ... not intended to differentiate
> > > > >      performance variations within the same service, e.g., high-speed
> > > > >      versus ordinary speed.  Performance variations can be supported
> > > > >      within a single assigned port number in context of separate
> > > > >      pairwise endpoint associations.
> > > > >
> > > > > The example about differentiated policies is not related to **
> > > performance ** but about being able to deliver a ** basic/normal **
> > > DOTS service. Such DOTS service takes place in attack times...during
> > > which links are saturated by nature.
> > > > >
> > > > > The purpose of DOTS is as such different from the typical usage
> > > > > of CoAP
> > > by IoT devices, DOTS signal channel is a new service.
> > > >
> > > > Yes.
> > > >
> > > > >
> > > > > (2)
> > > > >
> > > > > The WG already considered in previous versions of the
> > > > > specification to
> > > use the existing CoAP port number (in compliance with RFC7605), but
> > > that design was abandoned by the WG for the reasons documented in
> the draft.
> > > >
> > > >
> > > > Okay.
> > > >
> > > > >
> > > > > (3)
> > > > >
> > > > > The built-in discovery of services and resources discussed in
> > > > > RFC 7252
> > > requires request and response between the peers, but DOTS protocol
> > > is designed to work in congested networks (because of DDoS attack)
> > > and the DOTS client during a volumetric DDoS attack may not be able
> > > to discover services and resources.
> > > > >
> > > > > During a DDoS attack, the incoming link is likely to be
> > > > > saturated and the
> > > DOTS client can only send requests but not receive responses from
> > > the server. Assigning a DOTS service port avoids the need for
> > > resource discovery and additional RTT involved before the mitigation
> > > request can be sent to the DOTS server.
> > > >
> > > > My understanding is that you anyway need to communication to the
> > > > Dots
> > > server at least once before you can request mitigation.
> > > So discovery should
> > > have been done previously and not when under attack. Further you
> > > also need to pre-configure or discover the server address.
> >
> > No, the DOTS client may or may not establish the signal channel session
> with the DOTS server when no attack traffic is present.
> 
> (Hmm, the quoting looks weird -- I am pretty sure that what you reply to
> here was from Mirja, not me.)
> 
> > >
> > > To reiterate: you have to learn a contact point for the DOTS server
> > > somehow (configuration of a hostname, automated discovery, etc.).
> > > Why can't the mechanism that gives you this contact information give
> > > you the full contact information, including port ?
> >
> > Yes, discovery of the DOTS port information is possible using
> https://tools.ietf.org/html/draft-ietf-dots-server-discovery-01 but DOTS
> server discovery is optional and DOTS server discovery may not succeed
> during DDoS attack time (DNS server may not be reachable). Further, using a
> dedicated port for DOTS avoids discovery of services and resources discussed
> in RFC7252, and reduces the local configuration to only the DOTS server
> domain name (and optionally DOTS server IP addresses), similar to the way
> DNS-over-(D)TLS server is configured just with authentication domain name
> (ADN) (see https://tools.ietf.org/html/rfc8310).
> 
> I'm going to focuses on "reduces the local configuration to only the DOTS
> server domain name".  I'm familiar with many configuration interfaces that
> allow for "host:port" to be given as easily as just "host", and my
> understanding of Mirja's question is about local configuration of "host:port"
> (since local configuration of "host" would otherwise be used).

The local configuration with ports gets more complicated with DOTS call home (please see https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-01#section-4.1). 

> (This assumes that fully automated discovery would handle everything, so it
> less interesting for the matter at hand.)

If default port is not assigned, discovery of the DOTS server port using S-NAPTR or DNS-SD becomes mandatory, and the challenge during an attack is the DNS server itself may be unreachable or 
the DNS server could be subjected to DDoS attacks (making it incapable to respond to DNS queries from the DOTS client). 

-Tiru

> 
> > >
> > > (To be fair, even if the answer to the above is "it can give you
> > > that information", we may still want a dedicated port for operator
> > > convenience, but we should be clear about what the actual
> > > justification/need is.)
> > >
> > > > >
> > > > > (4)
> > > > >
> > > > > During a DDoS attack, the traffic from the endpoints and IoT
> > > > > devices can
> > > be rate-limited or blocked, but DOTS protocol traffic needs to be allowed.
> > > Assigning a DOTS service port helps middleboxes to identify and not
> > > rate- limit the DOTS protocol traffic during DDoS attack.
> > > >
> > > > This is not a great approach and the additional attack vector I’ve
> > > > been
> > > taking about. If everything but the dots port is block or
> > > rate-limited, then an attacker is probably tempted to run their
> > > attack using the designated dots port.
> > >
> > > I would actually split this into at least two related attack vectors:
> > >
> > > (1) if DOTS operates on a well-known port, that port is a target of
> > > attack, to disrupt the DOTS operation
> > > (2) if the well-known DOTS port receives preferential treatment, it
> > > becomes an attractive tool to use as part of an attack, since attack
> > > traffic could get prioritized over regular traffic.
> >
> > The above attack vectors are also possible if DOTS uses the CoAP port
> number 5684. If the DDoS mitigation provider is capable of protecting the
> target network resources, it will anyways be capable of protecting its own
> DOTS server from DDoS attacks. Further, the DOTS server in the ISP will only
> be reachable to its subscribers, and not visible to the external world.
> >
> > >
> > > > >
> > > > > (5)
> > > > >
> > > > > Given the rise of DDoS attacks targeting CoAP-capable IoT
> > > > > objects
> > > (usually, low-cost, not maintained,..), policies to filter "legacy"
> > > CoAP messages (at the CPE + access/transit networks) will have
> > > implications on the delivery of DOTS service which is a key
> > > component for the emergence of protective networking architectures.
> > > Having means to differentiate traditional CoAP service from DOTS are
> > > important from a deployment standpoint.
> > > >
> > > > This is not a good approach either. The port number at maximum
> > > > could be
> > > used as a hint but you really need to apply different means to
> > > identify dots traffic as everybody including attack traffic could just use the
> dots port.
> >
> > Agreed, having a separate port number is a good hint for the
> > middle-boxes (middle-box knows the port is only used for DOTS traffic, and
> any other type of traffic can be blocked).
> >
> > > >
> > > > > ====
> > > > >
> > > > >>
> > > > >> 2) Section 4.3 says:
> > > > >> "In reference to Figure 4, the DOTS client sends two TCP SYNs and
> two
> > > > >>   DTLS ClientHello messages at the same time over IPv6 and IPv4."
> > > > >> However, RFC8305 explicitly states that connection attempts
> > > > >> SHOULD NOT be made simultaneously (see sec 5).
> > > > >>
> > > > >
> > > > > [Med] This one is discussed in another thread.
> > > >
> > > > My discuss point was actually different. Due over network
> > > > overload,
> > > probing should NOT be done simultaneously. However, I’ve seen that
> > > you now also changed the mechanism to only use simultaneous probing
> > > when under attack. That may be fine, however, it is not fully clear
> > > why happy eyeballs would be needed at all during an attack as the
> > > assumption is that you always have an active session (starting
> > > before the attack). I would further like to see it made even more
> > > clear that probing MUST be performed sequentially (as described in
> RFC8305) otherwise.
> > >
> > > Another (I think) way to phrase this would be: "if the network is
> > > under attack, it's already in congestion crisis.  Transmitting lots
> > > of stuff simultaneously sounds like making the congestive collapse worse,
> rather than helping."
> >
> > Several DDoS attacks do not congest the network (e.g. Slowloris), we can
> update the text as follows:
> >
> >  When connection attempts are made during an attack congesting the
> > network, the DOTS client  SHOULD use a "Connection Attempt Delay"
> [RFC8305] set to 100 ms.
> 
> Thanks for pointing out that not all attacks are brute bandwidth (or pps).
> I'd like to hear from Mirja at this point.
> 
> > >
> > > > >
> > > > >> Further Figure 4 shows a different order of request as
> > > > >> recommended in the text (text says: "UDP over IPv6, UDP over
> > > > >> IPv4, TCP over IPv6, and finally TCP over IPv4").
> > > > >
> > > > > [Med] Actually, the text says:
> > > > >
> > > > >  "In reference to Figure 4, the DOTS client sends two TCP SYNs and
> two
> > > > >   DTLS ClientHello messages at the same time over IPv6 and IPv4. "
> > > > >
> > > > > We will add annotations to the figure.
> > > > >
> > > > > Also why are the UDP connection attempts repeated? I guess that
> > > > > is
> > > > >> meant to be the retransmission of the DTLS Hello?
> > > > >
> > > > > [Med] Yes.
> > > > >
> > > > > However, usually you should
> > > > >> receive the TCP SYNACK before you retransmit
> > > > >
> > > > > [Med] What is retransmitted is DTLS.
> > > > >
> > > > > or in the best case even before
> > > > >> you start the next connection attempt. Therefore that should be
> > > > >> not displayed like this in the figure or needs further explanation.
> > > > >
> > > > > [Med] We will add annotations to the figure.
> > > > >
> > > > >>
> > > > >> 3) Why are these statements SHOULDs and not MUSTs (see section
> 4.4)?
> > > > >>  "DOTS agents SHOULD follow the data transmission guidelines
> > > discussed
> > > > >>   in Section 3.1.3 of [RFC8085] and control transmission behavior by
> > > > >>   not sending more than one UDP datagram per round-trip time (RTT)
> to
> > > > >>   the peer DOTS agent on average."
> > > > >
> > > > > [Med] because we are aligned with 8085 which says:
> > > > >
> > > > > " SHOULD still control their transmission behavior by not
> > > > >   sending on average more than one UDP datagram per RTT to a
> > > > >   destination “
> > > >
> > > > RFC8085 uses SHOULD because it’s a gnernic guideline document for
> > > > all
> > > protocols that use UPD. If there is no good reason to do otherwise
> > > in a specific protocol spec, as dots is, you need to pick suitable
> > > values and define them with a MUST.
> > >
> > > +1
> >
> > I don't have a good reason to pick different values, will replace "SHOULD"
> with "MUST".
> 
> Thanks.
> 
> -Ben
> 
> > >
> > > > >
> > > > >> and
> > > > >>  "If the DOTS client cannot maintain an RTT estimate, it
> > > > >>   SHOULD NOT send more than one Non-confirmable request every
> 3
> > > > >>   seconds"
> > > > >
> > > > > [Med] because 8085 says:
> > > > >
> > > > > "Such applications SHOULD NOT send more than one UDP
> > > > >       datagram every 3 seconds”
> > > >
> > > > Same as above.
> >
> > I don't have a valid reason to be more aggressive, will replace "SHOULD"
> with "MUST".
> >
> > > > >
> > > > >
> > > > >> as well as in section 4.4.2.1:
> > > > >>  "If the DOTS server cannot maintain an RTT
> > > > >>   estimate, it SHOULD NOT send more than one asynchronous
> > > notification
> > > > >>   every 3 seconds"
> > > > >
> > > > > [Med] Idem as above.
> > > >
> > > > Same as above.
> >
> > I don't have a valid reason to be more aggressive, will replace "SHOULD"
> with "MUST".
> >
> > > >
> > > > >
> > > > >> and again in section 4.4.2.2:
> > > > >> "The frequency of polling the DOTS server to get the
> > > > >>   mitigation status SHOULD follow the transmission guidelines in
> > > > >>   Section 3.1.3 of [RFC8085].
> > > > >
> > > > > [Med] This is to accommodate the case where a local policy is
> > > > > provided to
> > > the DOTS agent.
> > > >
> > > > You need specify this further. A reference to RFC8085 alone is
> > > > never
> > > enough.
> > > >
> > > > >
> > > > >> However, most of the communication pattern used by DOTS rely on
> > > > >> a request/reply pattern and Coap specifies for this case that
> > > > >> only one request can be outstanding at a time (until the reply
> > > > >> is received or message is assumed to be
> > > > >> lost) (see section 4.7 and 4.2 of RFC7252) which therefore will
> > > > >> be used in this case. Only migration updates are send without
> > > > >> reply, and here a MUST would be more appropriate.
> > > > >>
> > > > >> Please also note that if there can only be one request
> > > > >> outstanding (before a reply is received) it is also not
> > > > >> possible that requests are received out of order (see e.g.
> > > > >> 4.4.3: "If UDP is used as transport, CoAP requests may arrive out-of-
> order.”).
> > > >
> > > > However, again as I said, the causes above should anyway not
> > > > resend
> > > message based on a 3 second timer because most of them are
> > > request/reply pattern and Coap specifies that there should always
> > > only be one request outstanding.
> > >
> > > FWIW, I think this "may arrive out-of-order" is my fault, as I think
> > > I asked for it during AD review (having missed the part where CoAP
> > > only admits one outstanding request).
> >
> > No, non-confirmable CoAP requests can arrive out-of-order at the
> > server, please see https://tools.ietf.org/html/rfc7252#section-4.3 and
> > https://tools.ietf.org/html/draft-ietf-lwig-coap-06#section-3.5
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > >
> > > > >>
> > > > >> 4) draft-ietf-core-hop-limit is used in section 10:
> > > > >> "The presence of DOTS gateways may lead to infinite forwarding
> loops,
> > > > >>   which is undesirable.  To prevent and detect such loops, this
> > > > >>   document uses the Hop-Limit Option."
> > > > >> This sounds like it should be required (and normative language
> > > > >> should be
> > > > >> used)
> > > > >> and therefore draft-ietf-core-hop-limit should also be a
> > > > >> normative
> > > reference.
> > > > >> Also draft-ietf-core-comi should probably another normative
> reference.
> > > > >
> > > > > [Med] These two items are already covered in the reply to
> > > > > Alexey's
> > > review.
> > > >
> > > > Okay, please move draft-ietf-core-hop-limit to normative.
> > > >
> > > > I don’t see any discussion about draft-ietf-core-comi…?
> > > >
> > > > >
> > > > >>
> > > > >> 5)Section 4.5.2: You give recommendations for min and max in a
> > > > >> note, however, these values should be specified normatively and
> > > > >> in
> > > best with a MUST.
> > > > >
> > > > > [Med] We can use RECOMMENDED.
> > > >
> > > > Yes, please use normative language here as well. Also why is
> > > > actually a
> > > maximum specified?
> > > >
> > > > >
> > > > >>
> > > > >> 6) Section 4.7: "the DOTS
> > > > >>   agent sends a heartbeat over the signal channel to maintain its half
> > > > >>   of the channel.  The DOTS agent similarly expects a heartbeat from
> > > > >>   its peer DOTS agent"
> > > > >> and
> > > > >> "DOTS servers MAY trigger their heartbeat requests immediately
> after
> > > > >>   receiving heartbeat probes from peer DOTS clients."
> > > > >> Actually heartbeat should only be send in one direction (as the
> > > > >> other end will send an ack) and the protocol should clearly
> > > > >> specify which endpoint is responsible for triggering the ping.
> > > > >>
> > > > >
> > > > > [Med] The current behavior us aligned with "SIG-004  Channel
> > > > > Health
> > > Monitoring" of https://tools.ietf.org/html/draft-ietf-dots-requirements-
> 22.
> > > >
> > > > Usually one ends send the heartbeats (ping) and the other end send
> > > > an ack
> > > (pong). There is no need for both ends to send heartbeats
> > > independently as the heartbeat and retransmission rate is known and
> > > therefore both ends can infer independently that the connection
> > > failed if no messages are received anymore. That also how I read SIG-004.
> > > >
> > > > >
> > > > >> 7) sec 7.3:"To avoid DOTS signal message fragmentation and the
> > > subsequent
> > > > >>   decreased probability of message delivery, DOTS agents MUST
> ensure
> > > > >>   that the DTLS record MUST fit within a single datagram."
> > > > >> This should be handled by the DTLS record layer and not by DOTS
> > > > >> that works on top of DTLS (actually Coap), therefor it seems
> > > > >> straight to have a normative requirement here in the DOTS spec.
> > > > >> Also note that the calculation provided is not valid for early
> > > > >> data
> > > > >> (0-RTT) as the hello messages could be transmitted in the same
> > > > >> datagram.
> > > > >>
> > > > >
> > > > > [Med] Will check this.
> > > > >
> > > > >> 8) Also sec 7.3: "If the path
> > > > >>   MTU is not known to the DOTS server, an IP MTU of 1280 bytes
> > > SHOULD
> > > > >>   be assumed."
> > > > >>  Actually this is only true for IPv6. The later note mentions
> > > > >> that the  situation is different from IPV4, however, it should
> > > > >> probably be made clear  from the beginning that 1280 can only
> > > > >> be assumed for
> > > IPv6.
> > > > >
> > > > > [Med] Actually, we are echoing RFC7252:
> > > > >
> > > > >   If the Path MTU is not known for a destination, an IP MTU of 1280
> > > > >   bytes SHOULD be assumed; if nothing is known about the size of the
> > > > >   headers, good upper bounds are 1152 bytes for the message size
> and
> > > > >   1024 bytes for the payload size.
> > > >
> > > >
> > > > The difference is that you previously say:
> > > >
> > > > "To avoid DOTS signal message fragmentation and the subsequent
> > > >    decreased probability of message delivery, DOTS agents MUST ensure
> > > >    that the DTLS record MUST fit within a single datagram.”
> > > >
> > > > If this is a hard requirement (using MUST), you also MUST limit
> > > > your
> > > message for IPv4 to 576 bytes.
> > > >
> > > > RFC7252, however says this instead:
> > > > "A CoAP message, appropriately encapsulated, SHOULD fit within a
> > > >    single IP packet (i.e., avoid IP fragmentation) and (by fitting into
> > > >    one UDP payload) obviously needs to fit within a single IP datagram.”
> > > >
> > > > Using SHOULD.
> > > >
> > > > >
> > > > >>
> > > > >> 9) sec 9.6: What's the registration policy for the newly created
> registries?
> > > > >>
> > > > >
> > > > > [Med] The text says the following:
> > > > >
> > > > >   New codes can be assigned via Standards Action [RFC8126].
> > > >
> > > > Okay. Missed that as it was below the table. May move the text
> > > > above the
> > > table. But this is of course fully editorial only.
> > > > >
> > > > >
> > > > >> 10) The document should more explicitly provide more guidance
> > > > >> about when a client should start a session and what should be
> > > > >> done (from the client side) if a session is detected as
> > > > >> inactive (other than during migration which is discussed a bit
> > > > >> in 4.7). Is the assumption to have basically permanently an
> > > > >> active session or connect for migration and configuration
> > > > >> requests separately at a time?
> > > > >
> > > > > [Med] In order to avoid cryptographic handshake for new
> > > > > mitigation
> > > requests, the session is assumed to be established and maintained.
> > > >
> > > > If the assumption is that you always have an active session, then
> > > > I actually
> > > don’t understand how you can have an happy eyeball procedure during
> > > an attack. Shouldn’t there already been an active session or at
> > > least a previous session which pre-cached information? Also if the
> > > connection is detected to be inactive, which peer should try to
> > > re-establish the connection? I guess only the client would, right? That
> need to be further specified!
> > > >
> > > >
> > > > >
> > > > >>
> > > > >>
> > > > >> ---------------------------------------------------------------
> > > > >> ----
> > > > >> ---
> > > > >> COMMENT:
> > > > >> ---------------------------------------------------------------
> > > > >> ----
> > > > >> ---
> > > > >>
> > > > >> 1) I really recommend to add subsections to section 4.4.1.
> > > > >>
> > > > >> 2) section 4.4.1: "The lifetime of the
> > > > >>         deactivated mitigation request will be updated to (retry-timer
> > > > >>         + 45 seconds), so the DOTS client can refresh the deactivated
> > > > >>         mitigation request after retry-timer seconds before expiry of
> > > > >>         lifetime and check if the conflict is resolved."
> > > > >> This wording is not fully clear to me. If the life time of a
> > > > >> deactivated request in updated, isn't it active again?
> > > > >
> > > > > [Med] A request can be updated but the status may be flagged as
> > > > > active
> > > or deactivate.
> > > >
> > > > Please specify explicitly what the status should be after adding
> > > > the 45
> > > seconds.
> > >
> > > I had a hard time with this wording, too; maybe my suggestions ended
> > > up making things worse eventually.  IIUC, the situation is "keep the
> > > request active and add another 45 seconds to the remaining lifetime".
> > >
> > > > > And if it is active and another
> > > > >> request is sent, isn't that request rejected again.
> > > > >
> > > > > [Med] Likely
> > > >
> > > > Then I don’t understand how this is supposed to work.
> > > > >
> > > > > Can you please further
> > > > >> clarify.
> > > > >>
> > > > >> 3) section 4.4.2: "lifetime:  The remaining lifetime of the
> > > > >> mitigation request, in
> > > > >>      seconds."
> > > > >> Shouldn't lifetime we rather a timestamp because there is some
> > > > >> unknown transmission delay between the time when the reply is
> > > > >> generated and the reply is received, and as such a lifetime in
> > > > >> seconds is quite meaningless for the client.
> > > > >
> > > > > [Med] We prefer lifetime because otherwise time synchronization
> > > > > will be
> > > needed. The use of lifetime is aligned with other similar usage:
> > > e.g., RFC6887, RFC8512, etc.
> > > >
> > > > I guess it also depends on what kind of time span we are talking
> > > > about. If it
> > > is only a few seconds, transmission delay might have a big impact.
> > > However, it probably could be good in any case to advise that a
> > > refresh of a mitigation request should not be send “last minute” as
> > > there is some fuzziness because of transmission delays.
> > >
> > > There's definitely a tradeoff here.  I think I'm leaning towards
> > > lifetime rather than timestamp for this use case.
> > >
> > > -Ben
> > >
> > > > >
> > > > >>
> > > > >> 4) section 4.4.2.1: " For DOTS server
> > > > >>   application, the message type MUST always be set to Non-
> confirmable
> > > > >>   even if the underlying COAP library elects a notification to be sent
> > > > >>   in a Confirmable message."
> > > > >> I'm not sure I understand this sentence. Can you please further
> explain?
> > > > >
> > > > > [Med] What is meant is to relax this behavior from RFC 7641:
> > > > >
> > > > >   A server that transmits notifications mostly in non-confirmable
> > > > >   messages MUST send a notification in a confirmable message instead
> of
> > > > >   a non-confirmable message at least every 24 hours.
> > > > >
> > > > > DOTS application will override that behavior.
> > > >
> > > > Okay. Would be good to provide a pointer to RFC7641 and further
> > > > clarify
> > > this in the document.
> > > >
> > > > >
> > > > >>
> > > > >> 5) section 4.4.4: "For example, if there is a financial
> > > > >>   relationship between the DOTS client and server domains, the
> DOTS
> > > > >>   client stops incurring cost at this point."
> > > > >> I find this sentence a bit problematic given the
> > > > >> active-but-terminating period is defined by server. Wouldn't
> > > > >> that mean the server can make me pay for undefined period of time?
> > > > >
> > > > > [Med] That is only an example if agreed between the client and
> server.
> > > Such considerations are out of scope.
> > > >
> > > > What I’m saying is that this is not a very good example for the
> > > > mechanism
> > > you provide. So either if that is a valid example, you should
> > > probably reconsider your mechanism or I’d advise you to not use this as
> an example.
> > > >
> > > > >
> > > > > Also the max of 300 sec doesn't seem to be a
> > > > >> MUST...?
> > > > >>
> > > > >
> > > > > [Med] Other values can be used in specific deployments/agreements.
> > > >
> > > > The text says:
> > > >
> > > > “.. MAY exponentially
> > > >    increase (the base of the exponent is 2) the active-but-terminating
> > > >    period up to a maximum of 300 seconds (5 minutes).”
> > > >
> > > > Which sounds like an explicit maximum and to clarify this I would
> > > recommend use of normative language. If that is not meant to be an
> > > actual must, then I would recommend rephrasing this sentence.
> > > >
> > > >
> > > >
> > > > >
> > > > >> 6) In section Section 4.5 you talk about Caop Ping/Pong.
> > > > >> However, these terms are not used in RFC7252. Maybe clarify
> > > > >> that empty confirmable  messages are used and provide a pointer
> > > > >> to section 4.2. of RFC7252 right here (instead of only later).
> > > > >
> > > > > [Med] Will do. Thanks.
> > > > >
> > > > >>
> > > > >> 7) High-level question: Given this doc specifies a YANG model,
> > > > >> why are configuration are not retrieved and changed using
> > > > >> NETCONF or
> > > RESTCONF?
> > > > >>
> > > > >
> > > > > [Med] The draft says the following:
> > > > >
> > > > >   This YANG module (ietf-dots-signal-channel) defines the DOTS client
> > > > >   interaction with the DOTS server as seen by the DOTS client.  A DOTS
> > > > >   server is allowed to update the non-configurable 'ro' entities in the
> > > > >   responses.  This YANG module is not intended to be used via
> NETCONF/
> > > > >   RESTCONF for DOTS server management purposes; such module is
> > > > > out
> > > of
> > > > >   the scope of this document.  It serves only to provide a data model
> > > > >   and encoding, but not a management data model.
> > > >
> > > > Yes, I understand why you want to use Coap when under attack.
> > > > However,
> > > the configuration part (Figure 19/20) is not done during the attack,
> > > therefore NETCONF/RESTCONF could be used (or it could even be part
> > > of the dots data channel).
> > > >
> > > > Mirja
> > > >
> > > >
> > > > >
> > > > > Thank you again for the detailed review.
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > >
> > >
> > > _______________________________________________
> > > Dots mailing list
> > > Dots@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dots