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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Tue, 05 March 2019 12:47 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 BAB091310B7; Tue, 5 Mar 2019 04:47:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 hbS1ZFhTar43; Tue, 5 Mar 2019 04:47:29 -0800 (PST)
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 56CA113106C; Tue, 5 Mar 2019 04:47:27 -0800 (PST)
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=1551789870; 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-microsoft-exchange-diagnostics:x-microsoft-antispam-prvs: 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=Bzqxg49pKdyjJp+AKIik/bV7R7M+DJOZ48GEwx BF3B8=; b=HOkO+L7jVxJPUOgMsweLDpg48cduvvuqHCiOcKbq mp2ny3GsY6FLDwEL/ptmDXM/ew+y6ai+2/sOOC6wW1rHLLXnHA VbDw0A+FVr8kIfwWe7M91yzHb5P29f/AWTZAziDD7kGgXTsHLA 8yywpq+UV7oSGRxzTd02E3rQ3t2906k=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 524e_cf16_b397a7e5_1861_4dc2_9517_360a1e2f13a8; Tue, 05 Mar 2019 05:44:29 -0700
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 05:47:03 -0700
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; Tue, 5 Mar 2019 05:47:03 -0700
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 5 Mar 2019 05:47:02 -0700
Received: from DM6PR16MB2794.namprd16.prod.outlook.com (20.178.225.219) by DM6PR16MB3067.namprd16.prod.outlook.com (10.255.61.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.16; Tue, 5 Mar 2019 12:47:00 +0000
Received: from DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::a948:401e:299e:4550]) by DM6PR16MB2794.namprd16.prod.outlook.com ([fe80::a948:401e:299e:4550%6]) with mapi id 15.20.1665.020; Tue, 5 Mar 2019 12:47:00 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
CC: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, "draft-ietf-dots-requirements@ietf.org" <draft-ietf-dots-requirements@ietf.org>, "dots@ietf.org" <dots@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)
Thread-Index: AQHUyfNmchRbiQkDSUaSyjwDnUu6AqXqVlbAgBKjugCAABRsMA==
Date: Tue, 05 Mar 2019 12:46:59 +0000
Message-ID: <DM6PR16MB2794E5D56B4584ED175FEDB3EA720@DM6PR16MB2794.namprd16.prod.outlook.com>
References: <155068522853.31498.10686203344983870104.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA23122@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <66BB8E3D-DEB6-43AC-AAEB-B6EB1A248865@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EA232A6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6EFF6377-02A4-4D0B-BCF2-313FDB3B18B8@kuehlewind.net> <787AE7BB302AE849A7480A190F8B93302EA2346F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790CA5915717C58079425D6EA7E0@BYAPR16MB2790.namprd16.prod.outlook.com> <1368787E-C78D-417A-972D-95CF9CA790EB@kuehlewind.net>
In-Reply-To: <1368787E-C78D-417A-972D-95CF9CA790EB@kuehlewind.net>
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: [49.37.201.107]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fe077e28-3f74-4de4-22a9-08d6a168a8cf
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR16MB3067;
x-ms-traffictypediagnostic: DM6PR16MB3067:
x-microsoft-exchange-diagnostics: 1;DM6PR16MB3067;23:gKYPxlhu/ofJkiyTT+aUf9BNUMBO5PzesfjRk/V09YZPn1B6piIZrE/6my5DM2kec582odYTdshgVDGFyZTMMHrbqLOXheKulZtThJ6gzbwhewd4IRPeyi1xGSOHkqJBTkBvtd2ZyCIW7+l7oEncC4dghRqOByIomwyib8lLrIZ32hr7Tz5/+kCyPaTjG78bir6P0CheV33JAiWlOpt8PGyMbMzCFJIt6Nj49ZnGy21WMcQzN/rOhJCFzPmiw7bODmQMfFrmWlBcq/Fi9yUM+wNhFbRG//1G8RC3YVs3yMk4QjL4LxuxeCe4K1I1eciKCdGUxa+MaaQz9ehHtap1YL0SKjjPVfDOhm/0qUC7HIvBOhmzCBd/TwZYn7BIymXd6mw3FTM6LoPUDLMK+V5t6rebg2WSS5+917fZRiObPSQxpbhWZuuR2bQOZtpuI+M0EATs4aAotiOfd7T2UeLXCLfcOE3VvO4s7plHbgbQ8ThoY77IG54Xy7tx8Ngocq608TPoRw9ULi3hiD9uk8GyrGG/i6+qLGwY437r+3rq6sJ00DQDUaAMVGFikYyPJmBLPCxTbC4wP4hRGlmI9H6VSWyrLmtTL7fFM1ikid643ope3+DqDiY1zvcClgmlZnzMObWk8k751D4OqSO6BqMiCLdSfXfCLHFyxtpapMw3cEyU2BZu8h3ebCOJvDqc1b4BRmnhPPiKI4aqLf5jH+SMPpEpE/3Lq+zAuelAx2mmMznYRscR9xdDx7vygwf5KhY6/RcaZgD/cOqXeLiui4MqYudD0wMd5VdHIhKrp9BvCGt4kajcctogHznOoSoynUWh37xa0zlpK7XqCCjBI2YWIlPU+8oBoCLc+Pm84CVs5NFa6qtOJx8hScMZWSVZg/1Q7AThzhrJJmvpQRHEdqESsU9BYXkvZnn65DyeJSQjVJo1hZdDTKjD/Auw3fbWko/WNX2ivnd+xLhNV5NAtcZVUrQeb+wyyxrdn2GNuNGmHCK22Xzr/6xS3PVErkXH46DvGgZB4yAyWKLFF3I1am1LKkPIzC21I2BwmiYbYyPmRQRtN/eR1+7vTWOI9asD3UnALVZ2uj67WngtNgXRBjhgdqH2MNar9Kwcu8RzdNFtJINyt2BKtp/Z+vbV/BvBrvnRjvkPOwa3RHkIA4QP+mBOomn7wUidB7JxXxXSUvKdfUePlJBxFWELa6dbh+hOFAuG99RaB2guZPhzPLpSA5V6bov3pdeyDDmv+it/bXZa4PE9RBSOPHi1kx9iVfWwnkg/wY3cC53UfOabVjlAJSO4xSCPVsyu+BfFylTGH6r3nhPHJbt+0mX2UXj04mtQbvvMy4iUPABRUp0Bzbltj3+NPuiB/s69wOig0trOhgpq0miiULwxft67HdJ/uyR6a4wb0YpiNYXT3/71YuXhYaBFgA==
x-microsoft-antispam-prvs: <DM6PR16MB30672F1A5B2F86C8C5984446EA720@DM6PR16MB3067.namprd16.prod.outlook.com>
x-forefront-prvs: 0967749BC1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(366004)(39860400002)(346002)(199004)(189003)(32952001)(13464003)(9686003)(55016002)(99286004)(54906003)(256004)(5024004)(14444005)(14454004)(2906002)(6436002)(186003)(5660300002)(26005)(52536013)(7696005)(33656002)(66066001)(476003)(486006)(102836004)(11346002)(53936002)(446003)(76176011)(6506007)(53546011)(6916009)(8936002)(68736007)(6246003)(316002)(81156014)(81166006)(305945005)(74316002)(7736002)(3846002)(6116002)(105586002)(224303003)(106356001)(229853002)(71190400001)(71200400001)(93886005)(66574012)(72206003)(478600001)(4326008)(97736004)(80792005)(25786009)(86362001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR16MB3067; H:DM6PR16MB2794.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: waaRJIdvLaCPoHtgW9xCelqHDP9YU5h3wcbbRErfJThtXgrqlYKI6M3SE/Ycsb4lTSdI5vq9qvlz+9LLnS0DMCllc9RLh0j8kMI0eSsZjebccXQALPz9wH9nw2X+H2fTO+pAkZ+XCuerfcd/zmEKKeEPASof/Hy4RYZpGldCojBndCr6J/YIaiGBV0fyQipa4ajfuqsETZow8yd4yYszscRyWwbDsL2S1DIte+xyh+gmKg8fmUegqP7mK75ows0weuJXqugiUImPQOHJdqo7L6rFBfrjp60cZldozDGf6SUDy7asCkpwvIqvW9CNKebUTvR8QOp/ANxL8BWwJG+T1z/9j+t4/5vsraarGnxV0fddzdci+QaT/aalSwHgaIlQy9ltvgnPgnY4gIIyPynWGosIobUmBgm9yOY+iIlKq/0=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fe077e28-3f74-4de4-22a9-08d6a168a8cf
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 12:46:59.8920 (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: DM6PR16MB3067
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.4
X-NAI-Spam-Version: 2.3.0.9418 : core <6495> : inlines <7025> : streams <1814823> : uri <2806964>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/xvCSdJKJ82BTwV8pUs7l2PjpLZc>
Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)
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: Tue, 05 Mar 2019 12:47:35 -0000

> -----Original Message-----
> From: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>
> Sent: Tuesday, March 5, 2019 5:02 PM
> To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> Cc: mohamed.boucadair@orange.com; dots-chairs@ietf.org;
> frank.xialiang@huawei.com; draft-ietf-dots-requirements@ietf.org;
> dots@ietf.org; The IESG <iesg@ietf.org>
> Subject: Re: [Dots] Mirja Kühlewind's Discuss on draft-ietf-dots-requirements-
> 18: (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.
> 
> Hi Tiru,
> 
> thanks, the proposed text works well for me!

Updated draft is published addressing the DISCUSS and comments from ISEG members.

Cheers,
-Tiru

> 
> Mirja
> 
> 
> 
> > Am 21.02.2019 um 15:58 schrieb Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>:
> >
> >> -----Original Message-----
> >> From: mohamed.boucadair@orange.com
> <mohamed.boucadair@orange.com>
> >> Sent: Thursday, February 21, 2019 8:10 PM
> >> To: Mirja Kuehlewind (IETF) <ietf@kuehlewind.net>
> >> Cc: dots-chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org;
> >> The IESG <iesg@ietf.org>; draft-ietf-dots-requirements@ietf.org
> >> Subject: RE: [Dots] Mirja Kühlewind's Discuss on
> >> draft-ietf-dots-requirements-
> >> 18: (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.
> >>
> >> Re-,
> >>
> >> My point is that combining RFC8085 and deployments where timers can
> >> be controlled/discovered is sufficient to fulfill the requirement.
> >>
> >> Of course, this does not guarantee that bindings are kept active if a
> >> NAT/FW assigns timers of less than 15 seconds...which is fair. The
> >> requirement does not ask for such guarantee.
> >
> > Agreed, I propose the following update to capture the discussion and
> addresses the comment:
> >
> > Channel Health Monitoring: DOTS agents MUST support exchange of
> heartbeat messages over the signal channel to monitor channel health. These
> keepalives serve the purpose to maintain any on-path NAT or Firewall bindings
> to avoid cryptographic handshake for new mitigation requests. The heartbeat
> interval during active mitigation could be negotiable based on NAT/Firewall
> characteristics. Absent information about the NAT/Firewall characteristics,
> DOTS agent needs to ensure its on-path NAT or Firewall bindings do not expire,
> by using the keep-alive frequency discussed in Section 3.5 of [RFC8085].
> >
> > Cheers
> > -Tiru
> >
> >>
> >> Cheers,
> >> Med
> >>
> >>> -----Message d'origine-----
> >>> De : Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] Envoyé :
> >>> jeudi 21 février 2019 14:46 À : BOUCADAIR Mohamed TGI/OLN Cc :
> >>> dots-chairs@ietf.org; frank.xialiang@huawei.com; dots@ietf.org; The
> >>> IESG; draft-ietf-dots-requirements@ietf.org
> >>> Objet : Re: [Dots] Mirja Kühlewind's Discuss on
> >>> draft-ietf-dots-requirements-
> >>> 18: (with DISCUSS and COMMENT)
> >>>
> >>> Hi Med,
> >>>
> >>> please see below.
> >>>
> >>>> Am 21.02.2019 um 13:17 schrieb mohamed.boucadair@orange.com:
> >>>>
> >>>>>>> 2) Also on this text in SIG-004:
> >>>>>>> "The heartbeat interval during active mitigation could be
> >>>>>>>    negotiable, but MUST be frequent enough to maintain any on-path
> >>>>>>>    NAT or Firewall bindings during mitigation.  When TCP is used as
> >>>>>>>    transport, the DOTS signal channel heartbeat messages need to be
> >>>>>>>    frequent enough to maintain the TCP connection state."
> >>>>>>>
> >>>>>>> As Joe commented already, different heartbeats at different
> >>>>>>> layers can
> >>> be
> >>>>>>> used
> >>>>>>> at the same time for different purposes. You can use heartbeats
> >>>>>>> at the application layer to check service availability while e.g.
> >>>>>>> using a
> >>> higher
> >>>>>>> frequent heartbeat at the transport layer to maintain firewall
> >>>>>>> and NAT
> >>>>> state.
> >>>>>>
> >>>>>> [Med] Please note that the text you quoted is about "during
> >>>>>> active
> >>>>> mitigation". When no attack is ongoing, we do have the following
> >>>>> behavior which covers your comment:
> >>>>>>
> >>>>>>    When DOTS agents are exchanging heartbeats and no
> >>>>>>    mitigation request is active, either agent MAY request changes to
> >>>>>>    the heartbeat rate.  For example, a DOTS server might want to
> >>>>>>                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>>>>    reduce heartbeat frequency or cease heartbeat exchanges when
> >>>>>> an
> >>>>>>
> >>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>>>>    active DOTS client has not requested mitigation, in order to
> >>>>>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>>>>    control load.
> >>>>>>
> >>>>>>> The advantage to such an approach is that there is less
> >>>>>>> application
> >>> layer
> >>>>>>> overhead/load e.g. in scenarios where it might be expensive to
> >>>>>>> wake up
> >>> the
> >>>>>>> application or a server is already highly loaded. Also note that
> >>>>>>> the
> >>>>> time-
> >>>>>>> outs
> >>>>>>> values of NATs and firewalls on the path are usually unknown,
> >>>>>>> therefore
> >>> an
> >>>>>>> application can never rely on heartbeats (no matter at which
> >>>>>>> level) and
> >>>>> must
> >>>>>>> be
> >>>>>>> prepared to try to reconnect on the application layer if the
> >>>>>>> connection fails.
> >>>>>>> Usually, the main reason for using heartbeats to maintain NAT or
> >>> firewall
> >>>>>>> state
> >>>>>>> (vs. reconnect every time) in TCP is if the application is time-
> >>> sensitive
> >>>>> and
> >>>>>>> a
> >>>>>>> full TCP handshake takes too long for the desired service. I'm
> >>>>>>> not sure
> >>>>> that
> >>>>>>> the case for DOTS, however, I understand it may be beneficial to
> >>>>>>> have established state if an attack is on-going.
> >>>>>>
> >>>>>> [Med] This is important to avoid new handshakes when the client
> >>>>>> has to
> >>>>> request a mitigation.
> >>>>>
> >>>>> This is okay but could be spelled out more explicitly as a
> >>>>> requirement, rather than taking about the details of sending heartbeats.
> >>>>>>
> >>>>>>>
> >>>>>>> For UDP I guess it's more complicated in your case. Time-outs
> >>>>>>> are
> >>> usually
> >>>>>>> very
> >>>>>>> short, however, state is created with the first packet of a flow
> >>>>>>> (as
> >>> there
> >>>>> is
> >>>>>>> no handshake in UDP). As you don't see blocking if state is
> >>>>>>> expired as
> >>> new
> >>>>>>> state is created immediately, it's kind of impossible to measure
> >>>>>>> the configured time-out values. Only if the firewall is under
> >>>>>>> attack it would start
> >>>>> blocking
> >>>>>>> UDP traffic that is has no state for yet. So I understand why it
> >>>>>>> is
> >>>>> desirable
> >>>>>>> to maintain UDP state for you, however, I don't understand how
> >>>>>>> you can
> >>>>> know
> >>>>>>> that your frequency is high enough to actually keep the state
> >>>>>>> open. Note
> >>>>> that
> >>>>>>> TCP time-outs are usually in the order of hours, while UDP
> >>>>>>> time-outs are usually in range of tens of seconds, and might
> >>>>>>> expire even quicker if a system is under attack. If that is a
> >>>>>>> scenario that is important for you, and assuming that not all
> >>>>>>> time-outs values on the path can be known, I guess it would
> >>>>> be
> >>>>>>> recommendable to use TCP instead.
> >>>>>>>
> >>>>>>> In any case this can not be a MUST requirement (as timers are
> >>>>>>> usually
> >>> not
> >>>>>>> known). I would recommend to state something like:
> >>>>>>>
> >>>>>>> "MAY be frequent enough to maintain NAT or firewall state, if
> >>>>>>> timer
> >>> values
> >>>>>>> are
> >>>>>>> known, or if TCP is used, SHOULD use in addition TCP heartbeats
> >>>>>>> to
> >>>>> maintain
> >>>>>>> the TCP connection state and reconnect immediately if a failure
> >>>>>>> is
> >>>>> detected."
> >>>>>>>
> >>>>>>
> >>>>>> [Med] The original wording is accurate and reflects the
> >>>>>> requirement of
> >>> the
> >>>>> WG. How this will be enforced is part of the solution/specification space.
> >>>>>
> >>>>> My hold point here is that
> >>>>>
> >>>>> "MUST be frequent enough to maintain any on-path NAT or Firewall
> >>>>> bindings during mitigation.“
> >>>>>
> >>>>> cannot be a MUST requirement as the network time-out values are
> >>>>> not known
> >>> by
> >>>>> the endpoints. Therefore it is impossible to fulfill this requirement.
> >>>>
> >>>> [Med] Two comments here:
> >>>> * The requirement can be fulfilled by relying RFC8085
> >>>> recommendations. This
> >>> is discussed in the spec documents.
> >>>
> >>> RFC8085 provide recommended value and limits, however, this does not
> >>> guarantee that the proposed values actually match the time-out
> >>> values as deployed on the path.
> >>>
> >>>> * there are deployments in which timers can be discovered (e.g.,
> >>>> PCP
> >>> (RFC6887)).
> >>>
> >>> This does not work in all cases and the draft does not seem to
> >>> require the usage of anything like this. If a requirement is that
> >>> the timeout values MUST be known in the deployed scenario, then that
> >>> should be spelled out, however, I assume that is not your intention
> >>> because that would limit deployment heavily.
> >>>
> >>> Mirja
> >>>
> >