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 > >>> > >
- [Dots] Mirja Kühlewind's Discuss on draft-ietf-do… Mirja Kühlewind
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… mohamed.boucadair
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Teague, Nik
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… mohamed.boucadair
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… mohamed.boucadair
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… mohamed.boucadair
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… mohamed.boucadair
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [Dots] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind (IETF)