Re: [secdir] [core] Secdir last call review of draft-ietf-core-too-many-reqs-04

Daniel Migault <daniel.migault@ericsson.com> Mon, 22 October 2018 07:01 UTC

Return-Path: <daniel.migault@ericsson.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3576130DFB for <secdir@ietfa.amsl.com>; Mon, 22 Oct 2018 00:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.364
X-Spam-Level:
X-Spam-Status: No, score=-4.364 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=RvgNX4AY; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=dhW7spK6
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 YweC_rhemL_d for <secdir@ietfa.amsl.com>; Mon, 22 Oct 2018 00:01:57 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 93DF2130E05 for <secdir@ietf.org>; Mon, 22 Oct 2018 00:01:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1540191710; x=1542783710; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=p0PKHW/YlznyH3DFz2ckM+9eAnVJ0j4iuRzKskw4ajQ=; b=RvgNX4AYupzsPLyevZM30wIqYDEnsIVtyzxN/f8IRTCAfEMrHxaukpYi4PQJJEVx F/8bjOBbrl3M81OivvuCjmZQ81vmMGHHEGsULWbATK4Q9xW4ERwkVeaqQba/le4r GX+xfnc96wuwfnYtfHJQL2lZ3gxMguLLSmcwm8p7TR8=;
X-AuditID: c1b4fb30-2bbff700000047d2-3e-5bcd75de3644
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DA.5F.18386.ED57DCB5; Mon, 22 Oct 2018 09:01:50 +0200 (CEST)
Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESBMB503.ericsson.se (153.88.183.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 22 Oct 2018 09:01:49 +0200
Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 22 Oct 2018 09:01:49 +0200
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 22 Oct 2018 09:01:49 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FgdLw3gnFRIEFt3Is/KSi5Dxg1AuHykrEzNVEz2Yp5k=; b=dhW7spK6BCXSzr6aLGXFAsysmZ30laQ+/tQwOZL2AiXjgSJ91EKcfDuUjInKx2dVwIfP3lpM5YyX+3JfXTJlX7T22pRAFBcVSPz6KiweSRiX0IjEkRFUJfMTy0ufh3LMagQTmt1USCR7zRKMG7vPu3lvoZE5VPFoiJ8nVixcgMU=
Received: from DM3PR15MB1002.namprd15.prod.outlook.com (10.166.160.10) by DM3PR15MB0650.namprd15.prod.outlook.com (10.164.33.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.29; Mon, 22 Oct 2018 07:01:46 +0000
Received: from DM3PR15MB1002.namprd15.prod.outlook.com ([fe80::2501:1ff1:91d0:8b6e]) by DM3PR15MB1002.namprd15.prod.outlook.com ([fe80::2501:1ff1:91d0:8b6e%4]) with mapi id 15.20.1250.028; Mon, 22 Oct 2018 07:01:42 +0000
From: Daniel Migault <daniel.migault@ericsson.com>
To: =?utf-8?B?QXJpIEtlcsOkbmVu?= <ari.keranen@ericsson.com>, "core@ietf.org" <core@ietf.org>
CC: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-core-too-many-reqs.all@ietf.org" <draft-ietf-core-too-many-reqs.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Jim Schaad <ietf@augustcellars.com>
Thread-Topic: [core] Secdir last call review of draft-ietf-core-too-many-reqs-04
Thread-Index: AQHUXydxRR2UxETJ3ES1rGo1Lxy5eaUqFC0AgADWWyA=
Date: Mon, 22 Oct 2018 07:01:42 +0000
Message-ID: <DM3PR15MB1002D5ADF7C18CD21B34627AE3F40@DM3PR15MB1002.namprd15.prod.outlook.com>
References: <153895864367.4396.18138201518799857673@ietfa.amsl.com> <061801d45f27$602ef380$208cda80$@augustcellars.com> <031D5D2F-69BA-4315-BC89-1F40363EF586@ericsson.com>
In-Reply-To: <031D5D2F-69BA-4315-BC89-1F40363EF586@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com;
x-originating-ip: [199.91.196.135]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM3PR15MB0650; 6:/7gVOFmtTjAVTRF4D95K7SaGPpXlsROuiF4plyQk+Yavb9wLpVEadyaoVwYMNLs9X/WRyCd5qZkeZO+z3GhWdztM0AN/X4i4hVkOTK4Y+R4kyozYaTR6CgTiXngfyFKD1KXxsVEqCZzBNA5xoQWsemBgzkBAXbFNzUu2wBq/VN8E+/Fc5CGIApvRhkd9uluuDUgDSCOOnAwYmnlMgkNKswp/EBh0ozB6wDTYjT0Ip2/O0iaaht55PonWbNtlZqFO9Qi2hd7XSpruY3uxz7SgyZNRZ3WtnXs6ed7xvhOsPVtXrqJkiY2OhbTgwijF9UO2RI2kmsYE6A/6tkDmlsriVHQ4GotOLS6+R+SZptDjvKTKYrjvl4NXT2T+Kl5yhiN1vr0F7VofLhuN4wnPMEzYAZaJAC4CjrRByGveEJnaJqjECvfdtRlqM8s78PaX0BZg7pTx0lVzSlqEEfAoCsbpRA==; 5:vR78pSSSK088LZMGUp5FXyeGM606CWInRSv3gpHDid8093CD+5qcD2WVLGI/aRG+nI87MkkBCR2dZ13+PxhMSbtVCiEE/TjOdUnJtTPKkJFlzx6uGdkwpYZjCr1GJkJq/t++DPgMycIxNh04+uInYdkyX40CtKV6XhvJXS7w6Sg=; 7:eSD6wEpttHHLKi6nDkbz0LA0WL/3lMedC0m6/pwkrmPIgUMUOi6KDQa1ff2qG/Ta15Yd8894wCRo2FNaAIBnm8M/H5mAowLQUCsSstdnXsv9QFU/ZgyNYNWml6lOZHTrZjua6+QBFRM1mQoEjokFN8WB2XJuxCXFx7LTAv5Wmeq8XFD1pMMZcuubYpO8WyaxepoBGlPqmsg6Bp5zhbqKqZzozGBpRHRqxTW0PwEb0154dP86dZ0ul70YswPvJnFU
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(346002)(39850400004)(376002)(189003)(199004)(13464003)(99286004)(54906003)(110136005)(606006)(14454004)(966005)(478600001)(76176011)(7696005)(25786009)(2906002)(4326008)(790700001)(3846002)(6116002)(561944003)(7736002)(186003)(66574009)(446003)(486006)(44832011)(86362001)(476003)(33656002)(26005)(74316002)(2501003)(97736004)(5250100002)(2900100001)(66066001)(81166006)(256004)(8936002)(11346002)(99936001)(81156014)(106356001)(8676002)(105586002)(14444005)(229853002)(5660300001)(68736007)(53546011)(6506007)(54896002)(6306002)(6436002)(102836004)(55016002)(316002)(71200400001)(236005)(71190400001)(9686003)(345774005)(6246003)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM3PR15MB0650; H:DM3PR15MB1002.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-office365-filtering-correlation-id: 7ca5d903-d96d-4344-7db0-08d637ec38fe
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:DM3PR15MB0650;
x-ms-traffictypediagnostic: DM3PR15MB0650:
x-microsoft-antispam-prvs: <DM3PR15MB0650D9ED908A809F4BD2DB91E3F40@DM3PR15MB0650.namprd15.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(248295561703944)(37575265505322)(166708455590820)(192374486261705)(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231355)(944501410)(4983020)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DM3PR15MB0650; BCL:0; PCL:0; RULEID:; SRVR:DM3PR15MB0650;
x-forefront-prvs: 08331F819E
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: SnNLBXTLhfArkAYkAcM3kSojQBH4dODSef+4Wqs02ot4q+luq5RrVA4QRFIeEda55NWftKMps3C3zW1SFuIliO9ElyC5oPvDNjkkv2/Ngg1pwVf3a/FsSXMrPWobZr2sbKIotlz/VNDhaL/67mrUCstAe/C/cNjGsNf+hyyA0TAbtCWi1yhfhM7XOAQMlmux8xpaANRAwsa3/p7HPWUqCY3MyUIhIcfr9NQTGBJ/6ymlqXh0UJ8nTdrWsATYL/0QBM4i7J6P+stU6z+pcSr06zVQv18DkXnZSXZk/jfrNLksvUQpE/zVMiwbaEfb5OjoEFD5WTeKJ48UQuLMEvcJsb40zVJ3jwHBShqMlfi3BAw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01D469B3.8CECAB10"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7ca5d903-d96d-4344-7db0-08d637ec38fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2018 07:01:42.5640 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR15MB0650
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSW0iTYRjHe7+Tn6vR25r5sChq1YVZ5qRoiJ3ACw0KC4JQsWZ95HGTba7j hVpKZJGVZK50mVZODTNjtoucrbRcTtJOOMxyljXMUqnZKKzt+xbU3e/5P//n9PKypMRLy9hM tZ7TqlU5ckZEVe5u068eynemRFf3SpXt482kssxUQysbK6YZ5WiLiVJO1AxTm+mElisVTEJd nY9IIpJFcfu5nEwDp12zca8ow/fqIplnqycOdb+YIAuQuZQ4hUJZwGvB97qYOYVErAR3Ihg0 zSAh8CKwjNrogIsP6rp2CYk6Aqyj96hAQOEyEqY+3yeEzHkCGicaSCFwI3hSXh8SqGdwDJTY z/IsxWnQcbWSN5G4F8F49bQ/wbLz8Q5wvcsSPDuhqNfDy1IcC7+HFQGZwivgue8yv7gYp0Jp yy9KmNWM4KG3mO8fijdDf5WTDDDCC2Da0cQXkDgcXO9NwaulMNz3lBE4DDwjM7TgTwPv5GlS 0OXw6csAEngR9JtKg9we4i+OFFgBj802/hbAbgbsN7/RgaUBb4Pi2ghB70Mw5rgUHLYSnCcK g55ssB6PL0MK4z/rGflnOYfg8vdBxsgfOg+6K99TgikFOizFIQJHwoeBD9RfvlEzRhr9bUn/ iFpj4v9ygDfAJ8fbYOlSKC8dDvI6GOucRFfR7AYUpuN06bkHYmKiOG3mPp1Oo45Sc/o7yP8D H9z9GX0PeT5usSPMIvkc8QjnTJHQKoPucK4dLff3cd9ufIZklFqj5uRScWK4Py3erzp8hNNq 9mjzczidHS1kKXm4WLm9NVmCD6j0XDbH5XHav1mCDZUVoKz4DFHPtmV6VWxmV9TPQ0Tr/er8 qq0y85BZM5665ai25PuiVbZNCUWmrmzXqinLifz0ptRjcet3mYvqr7UWNsw9n9X25qQh/pH7 hybiVljPy6POWdZN1uSTTPqFG51tSyzuhsSaisXHacMTeVKSwzoSH37H03HmYNWU2zPw9bqr XE7pMlSKlaRWp/oDrMLQeYkDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/hM1vghA-Twx1C3r4cq57KN8KFA8>
Subject: Re: [secdir] [core] Secdir last call review of draft-ietf-core-too-many-reqs-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2018 07:02:01 -0000

Hi Ari!

 

I checked the version on github.  It addresses my concerns also considering Jim’s feed backs. 

 

Yours, 

Daniel

From: Ari Keränen 
Sent: Sunday, October 21, 2018 2:10 PM
To: Daniel Migault <daniel.migault@ericsson.com>;; core@ietf.org
Cc: secdir@ietf.org; draft-ietf-core-too-many-reqs.all@ietf.org; ietf@ietf.org; Jim Schaad <ietf@augustcellars.com>;
Subject: Re: [core] Secdir last call review of draft-ietf-core-too-many-reqs-04

 

Thank you for the review Daniel!

 

I have now addressed your comments in the latest draft version in Github:

https://github.com/core-wg/too-many-reqs/pull/4/files

 

* Clarified the text in sections 4 and 5 roughly as proposed

* Added a note in section 5 that dropping requests may result in retries 

* Added a note that responses without encryption can leak information (agree with Jim that it’s not a major risk so didn’t add normative language on this)

 

I’m planning to submit a new version tomorrow before the DL.

 

 

Cheers,

Ari


On 8 Oct 2018, at 19.53, Jim Schaad <ietf@augustcellars.com <mailto:ietf@augustcellars.com> > wrote:






-----Original Message-----

From: core <core-bounces@ietf.org <mailto:core-bounces@ietf.org> > On Behalf Of Daniel Migault

Sent: Sunday, October 7, 2018 5:31 PM

To: secdir@ietf.org <mailto:secdir@ietf.org> 

Cc: draft-ietf-core-too-many-reqs.all@ietf.org <mailto:draft-ietf-core-too-many-reqs.all@ietf.org> ; ietf@ietf.org <mailto:ietf@ietf.org> ;

core@ietf.org <mailto:core@ietf.org> 



Subject: [core] Secdir last call review of

draft-ietf-core-too-many-reqs-04



 

Reviewer: Daniel Migault

Review result: Has Nits

 

Hi,

 

Reviewer: Daniel Migault

Review result: Has Nits

 

I have reviewed this document as part of the security directorate's

ongoing



effort to review all IETF documents being processed by the IESG. These

comments were written primarily for the benefit of the security area

directors.



Document editors and WG chairs should treat these comments just like any

other last call comments.

 

The document is clear and almost ready.  Most of my comments concerns the

"Security Considerations".

 

Yours,

Daniel

 

4.  CoAP Client Behavior

 

  A client MUST NOT rely on a server being able to send the 4.29

  Response Code in an overload situation because an overloaded server

  may not be able to reply to all requests at all.

 

<mglt>

 

I believe the sentence may be rephrased. This is just a proposal.

OLD

  may not be able to reply to all requests at all.

NEW

  may not be able to reply (at all) to some requests. .

 

</mglt>

 

5.  Security Considerations

 

  Replying to CoAP requests with a Response Code consumes resources

  from a server.  For a server under attack it may be more appropriate

  to simply drop requests without responding.

 

<mglt>

The gain from the response with Too Many Requests Response Code is almost

the current response and all *similar* requests from that client during

Max



Age. I suspect that is likely a gain except when there is no responses

from the



server and client is not expect to send a request before Max Age. Simply

dropping the requests may add the retry traffic, though it depends on the

application. That said your text is correct. I am wondering if it would be

good to



illustrate your purpose. </mglt>

 

  If a CoAP reply with the Too Many Requests Response Code is not

  authenticated and integrity protected, an attacker can attempt to

 

Keranen                 Expires January 25, 2019                [Page 3]

 

Internet-Draft  Too Many Requests Response Code for CoAP       July 2018

 

  spoof a reply and make the client wait for an extended period of time

  before trying again.

 

<mglt>

A similar attack may also consists in an attacker triggering multiple

request or



transactions with a spoofed IP so the server generates the reply to the

legitimate IP. This could be used if an attacker cannot directly send the

spoofed



response to the legitimate client.

 

The response code provides an information about the state (overloaded) of

the



server which can be used to infer additional information. This could

potentially



be used by an active attacker among other to confirm an attack is

efficient,



that a server is receiving multiple packet at a given time which may be

used to



identify some traffic patterns, identifying a bug a version...  For a

passive



attacker, the response code may among other indicate an appropriated time

to



trigger a larger attack....

 

Because the code enable an attacker to gain some kind of control of the

client,



and reveals some information about the status of the server. I would

suggest to



mention that Too Many Response Code should not be considered outside

unprotected channel. That is a server SHOULD NOT reply with a Too Many

Requests Response Code unless the communication is encrypted. A client

SHOULD ignore Too Many Response Code unless the communication is

encrypted.

 

The response seems to me small enough so reflection attacks may be out of

scope.


I do not believe that this is aimed to be any type of DOS prevention tool.
I would disagree that this is a huge attack window.  The client will filter
the set of response that it is receiving to match only requests that it has
made.  Thus a general flood attack would not be useful unless it was
targeting the same messages ids (and tokens) as requests from the client
under attack.  But then these would be seen by the server as duplicate
messages and ignored w/o sending out a response.

I am not sure that I would consider the fact that the server is currently
"loaded" for some measure is a huge leak of information.  I don't think I
would care if that was leaked. 

Jim




</mglt>

 

_______________________________________________

core mailing list

core@ietf.org <mailto:core@ietf.org> 

https://www.ietf.org/mailman/listinfo/core