From david.black@emc.com Fri Oct 4 15:48:54 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1021F9C83 for ; Fri, 4 Oct 2013 15:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVhOxWQpEqwn for ; Fri, 4 Oct 2013 15:48:50 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 444C921F9CC7 for ; Fri, 4 Oct 2013 15:48:49 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r94MmmvF007885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Oct 2013 18:48:48 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r94MmmvF007885 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1380926928; bh=IAszY2OVRp6QKODCwhWC4MrTtnY=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=auBZBKLqkGoHtiHVeGUkTwY+fkuXBWP3xU0kgTF6ent4qUM5lHBR6LA+ojGJAgtRS 2VgXXRaHbN9iGXaSor0pgAO5UimeuLKsT38YsNMPbMzQfyA5EF/ypgkebM7BKCSB2A m7yDDMa1Cqttj5iszyaSSXIw6exQzo5Q79cfV1so= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r94MmmvF007885 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd06.lss.emc.com (RSA Interceptor) for ; Fri, 4 Oct 2013 15:48:31 -0700 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r94MmUNe027854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Oct 2013 18:48:31 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Fri, 4 Oct 2013 18:48:30 -0400 From: "Black, David" To: "tsvwg@ietf.org" Date: Fri, 4 Oct 2013 18:48:29 -0400 Thread-Topic: NOMCOM 2013 - Second Call for Nominations - two weeks left Thread-Index: Ac7BJ8WnxuOraWIeTxmgo0+7W6QmTwALAhqA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712025DCE1F6E@MX15A.corp.emc.com> References: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> In-Reply-To: <20131004173149.22991.14931.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-EMM-GWVC: 1 X-RSA-Classifications: DLM_1, public, GIS Solicitation X-EMM-McAfeeVC: 1 Subject: [tsvwg] FW: NOMCOM 2013 - Second Call for Nominations - two weeks left X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 22:48:54 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlldGYtYW5ub3VuY2UtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE5vbUNvbSBDaGFpciAyMDEzDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMDQsIDIwMTMgMToz MiBQTQ0KVG86IElFVEYgQW5ub3VuY2VtZW50IExpc3QNCkNjOiBJRVRGIERpc2N1c3MgTGlzdA0K U3ViamVjdDogTk9NQ09NIDIwMTMgLSBTZWNvbmQgQ2FsbCBmb3IgTm9taW5hdGlvbnMgLSB0d28g d2Vla3MgbGVmdA0KDQpOb21pbmF0aW9ucyBmb3IgdGhlIElFU0csIElBQiwgYW5kIElBT0MgYXJl IGR1ZSB0byB0aGUgTm9tY29tIGJ5IEZyaWRheSwgMTggT2N0b2JlciwgMjAxMy4NCg0KSXMgdGhl cmUgc29tZW9uZSB5b3Ugd29yayB3aXRoIGF0IElFVEYgd2hvIGhhcyBsZWFkZXJzaGlwIHBvdGVu dGlhbCBhbmQgYSBncm93aW5nIHRyYWNrIHJlY29yZD8gUGxlYXNlIHJlYWQgdGhlIE5vbWNvbSBj YWxsIGZvciBub21pbmF0aW9ucyBhbmQgY29uc2lkZXIgbm9taW5hdGluZyBoZXIgb3IgaGltLiBP ciBzZXZlcmFsIGZvbGtzISBEZWFkbGluZSBmb3Igbm9taW5hdGlvbnMgaXMgT2N0b2JlciAxOC4g IE5vbWluYXRlIHNvb24gdG8gZ2l2ZSB5b3VyIG5vbWluZWUocykgcGxlbnR5IHRpbWUgdG8gZmls bCBpbiB0aGUgcXVlc3Rpb25uYWlyZS4gSW5mb3JtYXRpb24gYWJvdXQgdGhlIGRlc2lyZWQgZXhw ZXJ0aXNlIGZvciBwb3NpdGlvbnMgaXMgaGVyZTogDQogICAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTMvZXhwZXJ0aXNlDQoNCkxvdHMgbW9yZSwgaW5jbHVk aW5nIHdoaWNoIHBvc2l0aW9ucyBhcmUgb3BlbiwgaG93IHRvIG1ha2UgYSBub21pbmF0aW9uLCBh bmQgaG93IHRvIA0Kc2VuZCB1cyB5b3VyIGZlZWRiYWNrIG9uIHRoZSBkZXNpcmVkIGV4cGVydGlz ZSwgZm9sbG93cy4NCg0KSUVURmVycywgbGV0J3MgaGVhciBmcm9tIHlvdSEgIE1ha2Ugbm9taW5h dGlvbnMsIGFjY2VwdCBub21pbmF0aW9ucyENCg0KSWYgeW91IGhhdmUgYW55IHF1ZXN0aW9ucyBh Ym91dCB0aGUgcHJvY2VzcywgZmVlbCBmcmVlIHRvIGdldCBpbiB0b3VjaCB3aXRoIG1lLg0KDQpC ZXN0IHJlZ2FyZHMsDQoNCkFsbGlzb24gZm9yIHRoZSBOb21jb20NCg0KQWxsaXNvbiBNYW5raW4g DQpOb21jb20gQ2hhaXIgMjAxMy0xNA0KDQotLS0tLSBUaGUgSW5mbyBZb3UgTmVlZCBmb3IgTm9t aW5hdGluZyAtLS0tLQ0KDQpUaGUgMjAxMy0xNCBOb21pbmF0aW5nIENvbW1pdHRlZSAoTm9tY29t KSBpcyBzZWVraW5nIG5vbWluYXRpb25zDQpmcm9tIG5vdyB1bnRpbCBPY3RvYmVyIDE4LCAyMDEz LiBUaGUgb3BlbiBwb3NpdGlvbnMgYmVpbmcgY29uc2lkZXJlZA0KYnkgdGhpcyB5ZWFyJ3MgTm9t Y29tIGNhbiBiZSBmb3VuZCBsYXRlciBpbiB0aGlzIHNlY3Rpb24sIGFuZCBhbHNvIG9uDQp0aGlz IHllYXIncyBOb21jb20gd2Vic2l0ZTogDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv bm9tY29tLzIwMTMvDQoNCk5vbWluYXRpb25zIG1heSBiZSBtYWRlIGJ5IHNlbGVjdGluZyB0aGUg Tm9taW5hdGUgbGluayBhdCB0aGUgdG9wIG9mDQp0aGUgTm9tY29tIDIwMTMgaG9tZSBwYWdlLCBv ciBieSB2aXNpdGluZyB0aGUgZm9sbG93aW5nIFVSTDogDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbm9tY29tLzIwMTMvbm9taW5hdGUvDQoNCk5vdGUgdGhhdCBub21pbmF0aW9ucyBt YWRlIHVzaW5nIHRoZSB3ZWIgdG9vbCByZXF1aXJlIGFuIGlldGYub3JnIA0KZGF0YXRyYWNrZXIg YWNjb3VudC4gWW91IGNhbiBjcmVhdGUgYSBkYXRhdHJhY2tlciBpZXRmLm9yZyBhY2NvdW50IA0K aWYgeW91IGRvbid0IGhhdmUgb25lIGFscmVhZHkgYnkgdmlzaXRpbmcgdGhlIGZvbGxvd2luZyBV Ukw6DQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvYWNjb3VudHMvY3JlYXRlLw0KDQpO b21pbmF0aW9ucyBtYXkgYWxzbyBiZSBtYWRlIGJ5IGVtYWlsIHRvIG5vbWNvbTEzIGF0IGlldGYu b3JnLg0KSWYgeW91IG5vbWluYXRlIGJ5IGVtYWlsLCBwbGVhc2UgaW5jbHVkZSB0aGUgd29yZCAi Tm9taW5hdGUiIGluIHRoZSBTdWJqZWN0DQphbmQgaW5kaWNhdGUgaW4gdGhlIGVtYWlsIHdobyBp cyBiZWluZyBub21pbmF0ZWQsIHRoZWlyIGVtYWlsIGFkZHJlc3MgKHRvDQpjb25maXJtIGFjY2Vw dGFuY2Ugb2YgdGhlIG5vbWluYXRpb24pLCBhbmQgdGhlIHBvc2l0aW9uIGZvciB3aGljaCB5b3UN CmFyZSBtYWtpbmcgdGhlIG5vbWluYXRpb24uIElmIHlvdSB1c2UgZW1haWwsIHBsZWFzZSB1c2Ug YSBzZXBhcmF0ZSBlbWFpbCBmb3INCmVhY2ggcGVyc29uIHlvdSBub21pbmF0ZSwgYW5kIGZvciBl YWNoIHBvc2l0aW9uIChpZiB5b3UgYXJlIG5vbWluYXRpbmcgb25lDQpwZXJzb24gZm9yIG11bHRp cGxlIHBvc2l0aW9ucykuDQoNClNlbGYtbm9taW5hdGlvbiBpcyB3ZWxjb21lISAgTm8gbmVlZCB0 byBiZSBzaHkuDQoNCk5vbWNvbSAyMDEzLTE0IHdpbGwgZm9sbG93IHRoZSBwb2xpY3kgZm9yICJP cGVuIERpc2Nsb3N1cmUgb2YgV2lsbGluZw0KTm9taW5lZXMiIGRlc2NyaWJlZCBpbiBSRkMgNTY4 MC4gIEFzIHN0YXRlZCBpbiBSRkMgNTY4MDogIlRoZSBsaXN0IG9mDQpub21pbmVlcyB3aWxsaW5n IHRvIGJlIGNvbnNpZGVyZWQgZm9yIHBvc2l0aW9ucyB1bmRlciByZXZpZXcgaW4gdGhlDQpjdXJy ZW50IE5vbWNvbSBjeWNsZSBpcyBub3QgY29uZmlkZW50aWFsIi4gV2lsbGluZyBub21pbmVlcyBm b3IgZWFjaA0KcG9zaXRpb24gd2lsbCBiZSBsaXN0ZWQgaW4gYSBwdWJsaWNseSBhY2Nlc3NpYmxl IHdheSAtIGFueW9uZSB3aXRoIGENCmRhdGF0cmFja2VyIGFjY291bnQgbWF5IGFjY2VzcyB0aGUg bGlzdHMuICBJbiBhbGwgb3RoZXIgd2F5cywgdGhlIA0KY29uZmlkZW50aWFsaXR5IHJlcXVpcmVt ZW50cyBvZiBSRkMgMzc3Ny9CQ1AxMCByZW1haW4gaW4gZWZmZWN0LiAgQWxsDQpmZWVkYmFjayBh bmQgYWxsIE5vbWNvbSBkZWxpYmVyYXRpb25zIHdpbGwgcmVtYWluIGNvbmZpZGVudGlhbCBhbmQg d2lsbA0Kbm90IGJlIGRpc2Nsb3NlZC4gIA0KDQpJbiBvcmRlciB0byBlbnN1cmUgdGltZSB0byBj b2xsZWN0IHN1ZmZpY2llbnQgY29tbXVuaXR5IGZlZWRiYWNrIGFib3V0DQplYWNoIG9mIHRoZSB3 aWxsaW5nIG5vbWluZWVzLCBub21pbmF0aW9ucyBtdXN0IGJlIHJlY2VpdmVkIGJ5IHRoZSANCk5v bWNvbSBvbiBvciBiZWZvcmUgT2N0b2JlciAxOCwgMjAxMy4gIFBsZWFzZSBzdWJtaXQgeW91ciBu b21pbmF0aW9ucyAgDQphcyBlYXJseSBhcyBwb3NzaWJsZSBmb3IgdGhlIHNha2Ugb2YgeW91ciBu b21pbmVlcywgYXMgd2UndmUgc2V0IHRoZSANCnF1ZXN0aW9ubmFpcmUgc3VibWlzc2lvbiBkZWFk bGluZSBmb3IgT2N0b2JlciAyNSwgMjAxMy4NCg0KVGhlIGxpc3Qgb2YgcGVvcGxlIGFuZCBwb3N0 cyB3aG9zZSB0ZXJtcyBlbmQgd2l0aCB0aGUgTWFyY2ggMjAxNCBJRVRGIG1lZXRpbmcsIA0KYW5k IHRodXMgdGhlIHBvc2l0aW9ucyBmb3Igd2hpY2ggd2UgYXJlIGFjY2VwdGluZyBub21pbmF0aW9u czogIA0KDQpJQU9DDQpDaHJpcyBHcmlmZml0aHMNCg0KSUFCDQpCZXJuYXJkIEFib2JhDQpNYXJj IEJsYW5jaGV0DQpSb3NzIENhbGxvbg0KRWxpb3QgTGVhcg0KSGFubmVzIFRzY2hvZmVuaWcNCg0K SUVTRw0KQmFycnkgTGVpYmEgKEFwcGxpY2F0aW9ucykNCkJyaWFuIEhhYmVybWFuIChJbnRlcm5l dCkNCkJlbm9pdCBDbGFpc2UgKE9wZXJhdGlvbnMgYW5kIE1hbmFnZW1lbnQpDQpHb256YWxvIENh bWFyaWxsbyAoUkFJKQ0KU3Rld2FydCBCcnlhbnQgKFJvdXRpbmcpDQpTZWFuIFR1cm5lciAoU2Vj dXJpdHkpDQpNYXJ0aW4gU3RpZW1lcmxpbmcgKFRyYW5zcG9ydCkNCg0KUGxlYXNlIGJlIHJlc291 cmNlZnVsIGluIGlkZW50aWZ5aW5nIHBvc3NpYmxlIGNhbmRpZGF0ZXMgZm9yIHRoZXNlDQpwb3Np dGlvbnMsIGFzIGRldmVsb3Bpbmcgb3VyIHRhbGVudCBpcyBhIHZlcnkgY3J1Y2lhbCByZXF1aXJl bWVudCBmb3INCnRoZSBJRVRGLiAgQWxzbywgcGxlYXNlIGdpdmUgc2VyaW91cyBjb25zaWRlcmF0 aW9uIHRvIGFjY2VwdGluZyBub21pbmF0aW9ucw0KeW91IHJlY2VpdmUuICANCiANClRoZSBzdW1t YXJpZXMgb2YgdGhlIGRlc2lyZWQgZXhwZXJ0aXNlIGZvciB0aGUgcG9zaXRpb25zLCBkZXZlbG9w ZWQgYnkgdGhlIA0KcmVzcGVjdGl2ZSBib2RpZXMsIGFyZSBmb3VuZCBhdDoNCg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9ub21jb20vMjAxMy9leHBlcnRpc2UvDQoNCkluIGFkZGl0aW9u IHRvIG5vbWluYXRpb25zLCB0aGUgTm9tY29tIHNlZWtzIGNvbW11bml0eSBpbnB1dCBvbiANCnRo ZSBwb3NpdGlvbnMgdGhlbXNlbHZlcy4gIFdlIG5lZWQgYW5kIHdlbGNvbWUgdGhlIGNvbW11bml0 eSdzIA0Kdmlld3MgYW5kIGlucHV0IG9uIHRoZSBqb2JzIHdpdGhpbiBlYWNoIG9yZ2FuaXphdGlv bi4gSWYgeW91IA0KaGF2ZSBpZGVhcyBvbiB0aGUgcG9zaXRpb25zJyByZXNwb25zaWJpbGl0aWVz IChtb3JlLCBsZXNzLCANCmRpZmZlcmVudCksIHBsZWFzZSBsZXQgdXMga25vdy4gIFlvdSBjYW4g c2VuZCB1cyBlbWFpbCBhYm91dCB0aGlzIHRvDQpub21jb20xMyBhdCBpZXRmLm9yZywgYW5kIHdl IHdpbGwgdXNlIHRoaXMgZmVlZGJhY2sgYWN0aXZlbHkuDQoNClRoYW5rIHlvdSBmb3IgeW91ciBo ZWxwIGluIG5vbWluYXRpbmcgYSBncmVhdCBwb29sIG9mIHN0cm9uZyBhbmQgaW50ZXJlc3RpbmcN Cm5vbWluZWVzIQ0KDQoNCg0KDQo= From michawe@ifi.uio.no Tue Oct 8 04:58:08 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58E521E8200 for ; Tue, 8 Oct 2013 04:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfeeU6mVXuDq for ; Tue, 8 Oct 2013 04:58:03 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id B73D421E81DA for ; Tue, 8 Oct 2013 04:58:01 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1VTVv7-0006we-SO for tsvwg@ietf.org; Tue, 08 Oct 2013 13:57:45 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1VTVv7-0000Hr-I2 for tsvwg@ietf.org; Tue, 08 Oct 2013 13:57:45 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_24569281-1FE8-4470-8D5D-E83F1FF5D84E" Date: Tue, 8 Oct 2013 13:57:45 +0200 Message-Id: <29171F8D-BD98-4D86-86B5-1CAC7E3D05D0@ifi.uio.no> To: tsvwg@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 16 msgs/h 10 sum rcpts/h 19 sum msgs/h 11 total rcpts 8235 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 33B2F6829760703D228FAC8A0D5659782C825AF3 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 10 total 3219 max/h 16 blacklist 0 greylist 0 ratelimit 0 Subject: [tsvwg] Call for participation: Transport Services X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:58:09 -0000 --Apple-Mail=_24569281-1FE8-4470-8D5D-E83F1FF5D84E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Sorry if you receive multiple copies of this! I sent it to all the lists = with potentially interested folks... (this should be okay to do = according to RFC5434, which says "various mailing lists"). A community of interest is being formed to gauge whether there is = sufficient interest to host a BOF at the London IETF, on the topic of = "Transport Services". The intention is to create a WG that would define = the set of services that transport protocols offer to applications, such = that applications could at some point in the future request a service, = not a protocol. This could foster innovation (protocols could be tried = out, with a fall-back, without requiring the application programmer to = include such functionality); it could also give more freedom to whatever = resides below the API to automatically make the best out of what it = currently has available. If you're interested in this problem space, please visit the related = webpage that I have set up: https://sites.google.com/site/transportprotocolservices/ There you'll find an initial stab at a charter and all information about = the mailing list - please join us and participate in discussions! = Thanks! Cheers, Michael= --Apple-Mail=_24569281-1FE8-4470-8D5D-E83F1FF5D84E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

A community of = interest is being formed to gauge whether there is sufficient interest = to host a BOF at the London IETF, on the topic of "Transport Services". = The intention is to create a WG that would define the set of services = that transport protocols offer to applications, such that applications = could at some point in the future request a service, not a protocol. = This could foster innovation (protocols could be tried out, with a = fall-back, without requiring the application programmer to include such = functionality); it could also give more freedom to whatever resides = below the API to automatically make the best out of what it currently = has available.

If you're interested in this = problem space, please visit the related webpage that I have set = up:
There = you'll find an initial stab at a charter and all information about = the mailing list - please join us and participate in discussions! = Thanks!

Cheers,
Michael
= --Apple-Mail=_24569281-1FE8-4470-8D5D-E83F1FF5D84E-- From nico@cryptonector.com Fri Aug 30 09:50:14 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74FA21E805F for ; Fri, 30 Aug 2013 09:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiPojQL2Bb0z for ; Fri, 30 Aug 2013 09:50:09 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3D68921F9F5B for ; Fri, 30 Aug 2013 09:50:05 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id D58462F406D for ; Fri, 30 Aug 2013 09:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=0d2KIJhlCh5s059EoIgr 5NHX5Ao=; b=jZAe8e0dtNzEtMZUhBdCMQDGP4BBP4uVHRWrlqye68VuHqKFErHH JLe+k3VBXSFqyBS1YCsbeTrhFZoSsED1eq6bJF/W+WmD4etXLN7kZhQGg6Mz5NWF oQQ4iy59FNbDSxgrZgxQB00BVZMm88awyAn6Mg1mI2Z9rSoxAMlWJ3E= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 6ED552F406A for ; Fri, 30 Aug 2013 09:50:03 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id l12so790630wiv.0 for ; Fri, 30 Aug 2013 09:50:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sygVlKKmo/WYP9ly4TUrUNeTXqf0uyzeStw7eYHKKyU=; b=WQN+kVmQFopyfipQSBYrXTC3sx7x7GMv6di/MeDK+Ea8U3uR12e5e+lq3jKJxqNkrM 4+neJm8CmP1+NhbtPOIU2vDcPL137z0KLdeLNbrdERng+dlUoTD9IXyKHL6I0toKKQb0 Nj3Fiv4HE8sVMFRNXPAR+iCnpdC7GVCusx+oYp/b4NF8iSwEY2iqNmvYaQzJ4NDLAcQk ZtDY0QKOfnMxRchfrF0XMMCLdW2AY0KDzr0PrbbsmHmb/duzDE3w0rMo1YMGI8xG8oTG 94F36sXyd9y1i5UhSRHPGEyMqtCQpm3s5rh639wCIktjoo/Zt2aW3eCWp6KZtJX38xKB IOIQ== MIME-Version: 1.0 X-Received: by 10.194.23.196 with SMTP id o4mr2061995wjf.62.1377881400302; Fri, 30 Aug 2013 09:50:00 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Fri, 30 Aug 2013 09:50:00 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Fri, 30 Aug 2013 09:50:00 -0700 (PDT) In-Reply-To: References: Message-ID: From: Nico Williams To: Roberto Peon Content-Type: multipart/alternative; boundary=047d7b5d9c6b68680204e52d03df X-Mailman-Approved-At: Thu, 10 Oct 2013 09:37:55 -0700 Cc: HTTP Working Group , tsvwg Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 30 Aug 2013 16:50:15 -0000 X-Original-Date: Fri, 30 Aug 2013 11:50:00 -0500 X-List-Received-Date: Fri, 30 Aug 2013 16:50:15 -0000 --047d7b5d9c6b68680204e52d03df Content-Type: text/plain; charset=UTF-8 - HTTP needs an XID so as to make it less dependent on octet stream transports. HTTP chunks, so there's no need for sub-channels, as long as an XID can be used to dissociate reply order from request order. - SCTP and similar should be implemented in user-space -- the OS/NIC should know nothing more than how to classify packets for dispatch purposes. UDP obviously facilitates this and has the benefit that middle boxes deal with it. - Multi-homing and name resolution should be abstracted from the app, even if they are handled within the app (in a library). - The tricky things are a) security (SYN forgery type attacks), and b) congestion control. We know how to do (a) with low latency sometimes (e.g., see TCP Fast Open). (b) is trickier; read with care (has the IAB said anything about this?). - User/service authentication and session crypto are orthogonal to the above: TLS and similar can be adapted to unreliable, unordered datagram delivery, and they have been (DTLS). This is not to say that we have nothing to do in this space, just that it's mostly orthogonal to the transport issues/wish-list. Nico -- --047d7b5d9c6b68680204e52d03df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

- HTTP needs an XID so as to make it less dependent on octet= stream transports.=C2=A0 HTTP chunks, so there's no need for sub-chann= els, as long as an XID can be used to dissociate reply order from request o= rder.

- SCTP and similar should be implemented in user-space -- th= e OS/NIC should know nothing more than how to classify packets for dispatch= purposes.=C2=A0 UDP obviously facilitates this and has the benefit that mi= ddle boxes deal with it.

- Multi-homing and name resolution should be abstracted from= the app, even if they are handled within the app (in a library).

- The tricky things are a) security (SYN forgery type attack= s), and b) congestion control.=C2=A0 We know how to do (a) with low latency= sometimes (e.g., see TCP Fast Open).=C2=A0 (b) is trickier; read with care= (has the IAB said anything about this?).

- User/service authentication and session crypto are orthogo= nal to the above: TLS and similar can be adapted to unreliable, unordered d= atagram delivery, and they have been (DTLS).=C2=A0 This is not to say that = we have nothing to do in this space, just that it's mostly orthogonal t= o the transport issues/wish-list.

Nico
--

--047d7b5d9c6b68680204e52d03df-- From nico@cryptonector.com Wed Sep 4 20:14:21 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2D411E8252 for ; Wed, 4 Sep 2013 20:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rku7ePN5VWrv for ; Wed, 4 Sep 2013 20:14:16 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 793A711E8249 for ; Wed, 4 Sep 2013 20:14:16 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id BFAD6598065 for ; Wed, 4 Sep 2013 20:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=iIAjpJbwV8MC1p0zqlD3 Kbvzi7M=; b=PjPm4TFsecYGh5fmyz+ZUVoZ0JtjT9U/zE9vKosR3D+kXfErocR8 O0N5llCNCthLf5EahD0qpoMUXEwtmSEQdUAePFAxX7N1ZwcSl3/TczQfYWuxAfdX muk5e7wk+fB03bQaJw6bwfAy4/9wOOsene+2Zf099eKz3MaRPpZx0sI= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 73380598058 for ; Wed, 4 Sep 2013 20:14:15 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id cb5so4340638wib.9 for ; Wed, 04 Sep 2013 20:14:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ftrYWf3sv+XyDer8kqROvV+YHnAY5zqy2PBVX3syV/A=; b=RNYj3zOf3jQzkcmx1vDtHFSMjS4eeBaZUY0tzZRLY81D25TkHzuruH5Ekmmwr6J4JM uwBYpbD5hYaDAfNS2tYg1c1oEyyhb5g7DWdjVmbaHA9Nw/EJ+gsOIJhtAeaxmSaxbuE9 p+PFzIXUKWfr+63qRqWPLAU0P7nImiSPNzxiWDRXNpBLHVnhSj+LxDQy3mVaBcfN+abC yIAW24p89F7nW2LofksU1RvUh4ZudN5kJQiTU0Ix+w2Q2C5RLiFIEASQp4fWKL7Tdw0Y uKhdkWKvS6vBQbP8D6pVHQnxjHq6xEHSdVMxV4uXJl+vOGrDF0RgV0xdkBbdjzrtCpca fy1Q== MIME-Version: 1.0 X-Received: by 10.194.235.138 with SMTP id um10mr5112795wjc.30.1378350853782; Wed, 04 Sep 2013 20:14:13 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Wed, 4 Sep 2013 20:14:13 -0700 (PDT) In-Reply-To: References: <5226782E.1020606@isi.edu> <2E28E89B-091F-45C0-8703-F05148B18AEA@isi.edu> <522769E7.4060609@isi.edu> <10D1B35A-0CFA-49BD-A13B-2E0A0F3D8B22@lurchi.franken.de> <5227B92E.8040307@isi.edu> <5227D8DF.8090109@isi.edu> Message-ID: From: Nico Williams To: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 10 Oct 2013 09:37:55 -0700 Cc: tsvwg , Joe Touch , HTTP Working Group , Michael Tuexen Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 05 Sep 2013 03:14:21 -0000 X-Original-Date: Wed, 4 Sep 2013 22:14:13 -0500 X-List-Received-Date: Thu, 05 Sep 2013 03:14:21 -0000 Yes, deployable means: doesn't require middle-box updates (NAAAAAAAAATs) and doesn't require OS vendors / kernel developers / distros to develop, package, and deliver an implementation. That pretty much means: plain TCP and plain UDP. Not IPsec (sure, IPsec can run over UDP, but apps can't all run their own IKEs), not SCTP (unless it's over UDP), not TCP-AO or anything of the sort. Things like SCTP over UDP will do. Lighter-weight protocols over UDP too. Just make sure to handle congestion. DJB's MinimaLT looks pretty good. Nico -- From touch@isi.edu Thu Oct 10 10:29:24 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5140821E80DE for ; Thu, 10 Oct 2013 10:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpXdTxVHgeuv for ; Thu, 10 Oct 2013 10:29:10 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3F33021E808E for ; Thu, 10 Oct 2013 10:29:04 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r9AHSh72019943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Oct 2013 10:28:44 -0700 (PDT) Message-ID: <5256E3CB.7040403@isi.edu> Date: Thu, 10 Oct 2013 10:28:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nico Williams References: <5226782E.1020606@isi.edu> <2E28E89B-091F-45C0-8703-F05148B18AEA@isi.edu> <522769E7.4060609@isi.edu> <10D1B35A-0CFA-49BD-A13B-2E0A0F3D8B22@lurchi.franken.de> <5227B92E.8040307@isi.edu> <5227D8DF.8090109@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Michael Tuexen , HTTP Working Group , tsvwg Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:29:24 -0000 On 9/4/2013 8:14 PM, Nico Williams wrote: > Yes, deployable means: doesn't require middle-box updates > (NAAAAAAAAATs) and doesn't require OS vendors / kernel developers / > distros to develop, package, and deliver an implementation. That > pretty much means: plain TCP and plain UDP. Not IPsec (sure, IPsec > can run over UDP, but apps can't all run their own IKEs), not SCTP > (unless it's over UDP), not TCP-AO or anything of the sort. > > Things like SCTP over UDP will do. By your set of requirements, *anything* over UDP would work fine. Including IPsec, TCP-AO, and anything else you can dream up. Thank you for moving the stack up one level, adding 20 bytes of header, and constraining the number of connections between two hosts (due to the limit of port numbers). Joe From touch@isi.edu Thu Oct 10 10:32:21 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EB511E8185 for ; Thu, 10 Oct 2013 10:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2t6LdILqnop for ; Thu, 10 Oct 2013 10:32:07 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0725521F9BC3 for ; Thu, 10 Oct 2013 10:32:06 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r9AHVl8n020796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Oct 2013 10:31:47 -0700 (PDT) Message-ID: <5256E483.3030005@isi.edu> Date: Thu, 10 Oct 2013 10:31:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nico Williams References: <5226782E.1020606@isi.edu> <2E28E89B-091F-45C0-8703-F05148B18AEA@isi.edu> <522769E7.4060609@isi.edu> <10D1B35A-0CFA-49BD-A13B-2E0A0F3D8B22@lurchi.franken.de> <5227B92E.8040307@isi.edu> <5227D8DF.8090109@isi.edu> <5256E3CB.7040403@! isi.edu> In-Reply-To: <5256E3CB.7040403@isi.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Michael Tuexen , HTTP Working Group , tsvwg Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 17:32:21 -0000 On 10/10/2013 10:28 AM, Joe Touch wrote: > > > On 9/4/2013 8:14 PM, Nico Williams wrote: >> Yes, deployable means: doesn't require middle-box updates >> (NAAAAAAAAATs) and doesn't require OS vendors / kernel developers / >> distros to develop, package, and deliver an implementation. That >> pretty much means: plain TCP and plain UDP. Not IPsec (sure, IPsec >> can run over UDP, but apps can't all run their own IKEs), not SCTP >> (unless it's over UDP), not TCP-AO or anything of the sort. >> >> Things like SCTP over UDP will do. > > By your set of requirements, *anything* over UDP would work fine. > Including IPsec, TCP-AO, and anything else you can dream up. > > Thank you for moving the stack up one level, adding 20 bytes of header, (I intended to make that 8, 28, or 48, depending on whether you embed another layer of IPv4 or IPv6 header too). > and constraining the number of connections between two hosts (due to the > limit of port numbers). > > Joe From michawe@ifi.uio.no Fri Oct 11 01:14:37 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781E11E8121 for ; Fri, 11 Oct 2013 01:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8YiMjTkjNbd for ; Fri, 11 Oct 2013 01:14:31 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) by ietfa.amsl.com (Postfix) with ESMTP id CDADA21F90AF for ; Fri, 11 Oct 2013 01:14:30 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1VUXre-00077A-N5; Fri, 11 Oct 2013 10:14:26 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1VUXre-0002Bj-5z; Fri, 11 Oct 2013 10:14:26 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_87E28245-9E70-4F58-9ABD-C1FD39F20AEE" From: Michael Welzl In-Reply-To: Date: Fri, 11 Oct 2013 10:14:25 +0200 Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 5 sum msgs/h 2 total rcpts 8402 max rcpts/h 40 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.502, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 23BFC9648624E810400C308160450F5A5B37A41F X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -64 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 3291 max/h 16 blacklist 0 greylist 0 ratelimit 0 Cc: HTTP Working Group , tsvwg Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 08:14:37 -0000 --Apple-Mail=_87E28245-9E70-4F58-9ABD-C1FD39F20AEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30. aug. 2013, at 18:50, Nico Williams wrote: > - HTTP needs an XID so as to make it less dependent on octet stream = transports. HTTP chunks, so there's no need for sub-channels, as long = as an XID can be used to dissociate reply order from request order. >=20 > - SCTP and similar should be implemented in user-space -- the OS/NIC = should know nothing more than how to classify packets for dispatch = purposes. UDP obviously facilitates this and has the benefit that = middle boxes deal with it. >=20 >=20 AFAIK a pretty well working version of SCTP in user-space exists, and = this is also what's used in Firefox for the rtcweb data channel. > - Multi-homing and name resolution should be abstracted from the app, = even if they are handled within the app (in a library). >=20 +1 > - The tricky things are a) security (SYN forgery type attacks), and b) = congestion control. We know how to do (a) with low latency sometimes = (e.g., see TCP Fast Open). (b) is trickier; read with care (has the IAB = said anything about this?). >=20 >=20 RFC 3714 is a congestion control related RFC from the IAB. There's also = more RFCs with general recommendations, and a RFC 5783 gives an overview = of all of them (up to the date of its publication). > - User/service authentication and session crypto are orthogonal to the = above: TLS and similar can be adapted to unreliable, unordered datagram = delivery, and they have been (DTLS). This is not to say that we have = nothing to do in this space, just that it's mostly orthogonal to the = transport issues/wish-list. >=20 > Nico > -- >=20 Cheers, Michael --Apple-Mail=_87E28245-9E70-4F58-9ABD-C1FD39F20AEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

- HTTP needs an XID so as to make it less = dependent on octet stream transports.  HTTP chunks, so there's no = need for sub-channels, as long as an XID can be used to dissociate reply = order from request order.

- SCTP and similar should be = implemented in user-space -- the OS/NIC should know nothing more than = how to classify packets for dispatch purposes.  UDP obviously = facilitates this and has the benefit that middle boxes deal with = it.


AFAIK a pretty well working version = of SCTP in user-space exists, and this is also what's used in Firefox = for the rtcweb data channel.

- Multi-homing and name resolution should be abstracted from = the app, even if they are handled within the app (in a = library).

+1

- The tricky things are a) security (SYN = forgery type attacks), and b) congestion control.  We know how to = do (a) with low latency sometimes (e.g., see TCP Fast Open).  (b) = is trickier; read with care (has the IAB said anything about = this?).


RFC 3714 is a congestion control = related RFC from the IAB. There's also more RFCs with general = recommendations, and a RFC 5783 gives an overview of all of them (up to = the date of its publication).

- User/service authentication and session crypto are = orthogonal to the above: TLS and similar can be adapted to unreliable, = unordered datagram delivery, and they have been (DTLS).  This is = not to say that we have nothing to do in this space, just that it's = mostly orthogonal to the transport issues/wish-list.

Nico
--

=

Cheers,
Michael

= = --Apple-Mail=_87E28245-9E70-4F58-9ABD-C1FD39F20AEE-- From nico@cryptonector.com Fri Oct 11 09:25:02 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428CD21E8114 for ; Fri, 11 Oct 2013 09:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLgRfItNEM0R for ; Fri, 11 Oct 2013 09:24:57 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3964521E8125 for ; Fri, 11 Oct 2013 09:24:56 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id ADD27674070 for ; Fri, 11 Oct 2013 09:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=xQSzH9gnAixD2DOigpau IWkh8Zk=; b=vteqcC66Ha8hfUYRsvn+u6jJHRtjc9VBawJiGpnuh44LxMr4qeoX PCwu5wRyvrIKqq/faIVgVNpDlb6XXx6G3vOAsXsjZePLAhm9JsgJJeGPJgYfPLCC FforllwUHj8tC8qBVuq2JW8Sv08h/U96WuyvSymsgc2tacTxcEQsnlw= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 60C44674074 for ; Fri, 11 Oct 2013 09:24:55 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hn3so416698wib.11 for ; Fri, 11 Oct 2013 09:24:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+iHQz8XiniQisDV+3gRz7clcqHu2vCDRerfsRGlz0dg=; b=AHuSTrNiegpDo48jVnt0B65dmUh7MnsiSK0kBzWkGeM88OKh/h/PNXK60g0N2QVheu HsyHAYNOyZ0D1iv0QD2VPdutihqRSccafO8q9EkeJfzgMa+X+0sS9+FBYMuq38ZCcQQG 1q22yCOhaCyTytfHNrO/FaJ1KCeGnwOj8RMEQyCiezsP7zXyjIH7KGA6xkoU1+lB72A3 nVl1o1WZnw5v1VnbGxWPYLT+N1iuYaT4ySoRA1f7id2dHAWJ9Zhx9aoVo4PcCk/D1pPL f8rDZOrH3KPcDBU5mguL+q6uzlDqoriIdLtN2Qj6r/n8kiGOpvdY8E3Trjco1d7PgdLt Q7HQ== MIME-Version: 1.0 X-Received: by 10.180.73.239 with SMTP id o15mr3912434wiv.36.1381508693391; Fri, 11 Oct 2013 09:24:53 -0700 (PDT) Received: by 10.216.165.5 with HTTP; Fri, 11 Oct 2013 09:24:53 -0700 (PDT) In-Reply-To: <5256E3CB.7040403@isi.edu> References: <5226782E.1020606@isi.edu> <2E28E89B-091F-45C0-8703-F05148B18AEA@isi.edu> <522769E7.4060609@isi.edu> <10D1B35A-0CFA-49BD-A13B-2E0A0F3D8B22@lurchi.franken.de> <5227B92E.8040307@isi.edu> <5227D8DF.8090109@isi.edu> <5256E3CB.7040403@isi.edu> Date: Fri, 11 Oct 2013 11:24:53 -0500 Message-ID: From: Nico Williams To: Joe Touch Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 11 Oct 2013 09:49:52 -0700 Cc: Michael Tuexen , HTTP Working Group , tsvwg Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 16:25:02 -0000 On Thu, Oct 10, 2013 at 12:28 PM, Joe Touch wrote: > On 9/4/2013 8:14 PM, Nico Williams wrote: >> Things like SCTP over UDP will do. > > By your set of requirements, *anything* over UDP would work fine. Including > IPsec, TCP-AO, and anything else you can dream up. Well, not TCP-AO. But, yes. > Thank you for moving the stack up one level, adding 20 bytes of header, and > constraining the number of connections between two hosts (due to the limit > of port numbers). As if it were my fault. It's not. Or as if blame for this can be properly allocated. And anyways, no, we could run lots of [end-to-end] things over UDP in such a way that the port numbers from the UDP header need not be repeated at higher layers. But being able to use a single port for lots of communications streams is useful to deal with the second problem you note. Nico -- From touch@isi.edu Fri Oct 11 17:26:00 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD92421E8103 for ; Fri, 11 Oct 2013 17:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtCYlcYlrtmN for ; Fri, 11 Oct 2013 17:25:55 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBE721E8116 for ; Fri, 11 Oct 2013 17:25:48 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9C0PBhu012175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Oct 2013 17:25:11 -0700 (PDT) Message-ID: <525896E6.8020503@isi.edu> Date: Fri, 11 Oct 2013 17:25:10 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nico Williams References: <2E28E89B-091F-45C0-8703-F05148B18AEA@isi.edu> <522769E7.4060609@isi.edu> <10D1B35A-0CFA-49BD-A13B-2E0A0F3D8B22@lurchi.franken.de> <5227B92E.8040307@isi.edu> <5227D8DF.8090109@isi.edu> <5256E3CB.7040403@isi.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Michael Tuexen , HTTP Working Group , tsvwg Subject: Re: [tsvwg] The List (of application-layer desired features) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 00:26:01 -0000 On 10/11/2013 9:24 AM, Nico Williams wrote: > On Thu, Oct 10, 2013 at 12:28 PM, Joe Touch wrote: >> On 9/4/2013 8:14 PM, Nico Williams wrote: >>> Things like SCTP over UDP will do. >> >> By your set of requirements, *anything* over UDP would work fine. Including >> IPsec, TCP-AO, and anything else you can dream up. > > Well, not TCP-AO. But, yes. TCP-AO would work fine, presuming it's TCP over UDP, or TCP over IP over UDP. >> Thank you for moving the stack up one level, adding 20 bytes of header, and >> constraining the number of connections between two hosts (due to the limit >> of port numbers). > > As if it were my fault. It's not. Or as if blame for this can be > properly allocated. "you" is also plural, and by encouraging this sort of approach, you are a member of the group. > And anyways, no, we could run lots of [end-to-end] things over UDP in > such a way that the port numbers from the UDP header need not be > repeated at higher layers. You can reinvent the entire IP stack over a single UDP port. We've been around this block before with HTTP. > But being able to use a single port for > lots of communications streams is useful to deal with the second > problem you note. Useful in what sense? More fragile when dealing with changes in routing that alter which NATs are traversed? Providing the ability to reinvent the entire IP stack above UDP in a way that won't (can't) interact correctly with the native IP stack? Joe From dreibh@iem.uni-due.de Tue Oct 15 12:44:23 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C35421F9AE6 for ; Tue, 15 Oct 2013 12:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpAv1dFPMTfx for ; Tue, 15 Oct 2013 12:44:18 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id BF06F21F9FC8 for ; Tue, 15 Oct 2013 12:44:17 -0700 (PDT) Received: from lupo.localnet (cm-84.215.18.138.getinternet.no [84.215.18.138]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r9FJiGul013805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 15 Oct 2013 21:44:16 +0200 From: Thomas Dreibholz To: tsvwg@ietf.org Date: Tue, 15 Oct 2013 21:33:47 +0200 Message-ID: <1937213.hnVIMu3tG6@lupo> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.11.2 (Linux/3.8.0-31-generic; KDE/4.11.2; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1659462.IAOTsGdPmz"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: [tsvwg] [Extended Deadline] Call for Papers of the PAMS 2014 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:44:23 -0000 --nextPart1659462.IAOTsGdPmz Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" We apologize if you receive multiple copies of this CFP. CALL FOR PAPERS The 4th International Workshop on Protocols and Applications with Multi= -Homing=20 Support (PAMS 2014) In conjunction with the 28th IEEE International Conference on Advanced=20= Information Networking and Applications (AINA 2014) Victoria, BC/Canada, May 13-16, 2014 http://simula.no/pams2014 The intent of our workshop is to bring together people from research an= d industry, in order to provide a discussion forum for state-of-the-art t= opics related to multi-homing on Network, Transport, Session and Application = Layers. The PAMS workshop will include full-paper sessions as well as a poster = session (with short presentations) to introduce preliminary ideas as well as wo= rk in progress. Workshops proceedings will be published by the IEEE CS Conference Publi= shing Service and will be included in the Digital Library. The main topics to be addressed include (but are not limited to): * Network Resilience by Multi-Homing * Network Architectures for Multi-Homed Systems * Performance Evaluation of Multi-Homed Systems * Deployment of Multi-Homed Protocols in Existing Networks with Middleboxes * Design and Implementation of Multi-Homed Systems * Testbeds for Multi-Homed Systems * Load Sharing and Load Balancing for Multi-Homed Systems * Mobility for Multi-Homed Systems * Protocols with Multi-Homing Support * Congestion and Flow Control of Multi-Homed Systems * Quality of Service for Multi-Homed Systems * Multi-Homing for Interconnection Networks * Security of Multi-Homed Systems * Application Deployment and Support for Legacy Applications * Cross-Layer Optimisation for Multi-Homed Systems * Multi-Homing in the Context of the Future Internet GENERAL CHAIRS: * Thomas Dreibholz, Simula Research Laboratory, Norway * Hakim Adhari, University of Duisburg-Essen, Germany PROGRAM CHAIRS: * Martin Becke, University of Duisburg-Essen, Germany * Thomas Dreibholz, Simula Research Laboratory, Norway PUBLICITY CHAIRS: * Glenford Mapp, Middlesex University, United Kingdom * Xing Zhou, Hainan University, China PROGRAM COMMITTEE * Hakim Adhari, University of Duisburg-Essen, Germany * =C4=B0lknur Ayd=C4=B1n, Farmingdale State College, U.S.A. * =C5=81ukasz Budzisz, Technische Universit=C3=A4t Berlin, Germany * Nicola Altan, ista International, Germany * Paul Amer, University of Delaware, U.S.A. * Anna Brunstr=C3=B6m, Karlstad University, Sweden * Ahmed Elmokashfi, Simula Research Laboratory, Norway * Kristian Evensen, Simula Research Laboratory, Norway * Simone Ferlin, Simula Research Laboratory, Norway * Ernst Gunnar Gran, Simula Research Laboratory, Norway * Michio Honda, Keio University, Japan * Seok Joo Koh, Kyungpook National University, South Korea * Amund Kvalbein, Simula Research Laboratory, Norway * Glenford Mapp, Middlesex University, United Kingdom * Michael Menth, University of T=C3=BCbingen, Germany * Preethi Natarajan, Cisco, U.S.A. * Brad Penoff, Google, U.S.A. * Esbold Unurkhaan, Mongolian University of Science and Technology,= =20 Mongolia * Alan Wagner, University of British Columbia, Canada * Thomas Volkert, Ilmenau University of Technology, Germany * Michael Welzl, University of Oslo, Norway * Xing Zhou, Hainan University, China IMPORTANT DATES * Paper Submission Deadline: November 1, 2013 (extended) * Author Notification: December 20, 2013 * Author Registration: January 28, 2014 * Camera-Ready Paper Submission: February 11, 2014 CONTACT For further information, please contact: * Thomas Dreibholz (dreibh@simula.no) * Hakim Adhari (hakim.adhari@uni-due.de) WEBSITE http://simula.no/pams2014 --nextPart1659462.IAOTsGdPmz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlJdmJsACgkQ32BbsHYPLWWHzgCfdEfeUYfLyyjPBVvEFXqM/WSA BmwAoI1ttfi0KEflZ6fGbPRAg4zSf6IZ =mV5K -----END PGP SIGNATURE----- --nextPart1659462.IAOTsGdPmz-- From gorry@erg.abdn.ac.uk Wed Oct 16 10:58:43 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0592E11E8289 for ; Wed, 16 Oct 2013 10:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0brkaMrv-LOr for ; Wed, 16 Oct 2013 10:58:37 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id F3F2511E822D for ; Wed, 16 Oct 2013 10:58:30 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 393252B44C0; Wed, 16 Oct 2013 18:58:30 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 22C952B40C5 for ; Wed, 16 Oct 2013 18:58:29 +0100 (BST) Message-ID: <525ED3C4.3050004@erg.abdn.ac.uk> Date: Wed, 16 Oct 2013 18:58:28 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: tsvwg WG References: <5203AD0F.5030907@neclab.eu> <20130808220232.GG3328@verdi> <012C3117EDDB3C4781FD802A8C27DD4F25C8D2ED@SACEXCMBX02-PRD.hq.netapp.com> <012C3117EDDB3C4781FD802A8C27DD4F25CE081A@SACEXCMBX02-PRD.hq.netapp.com> In-Reply-To: <012C3117EDDB3C4781FD802A8C27DD4F25CE081A@SACEXCMBX02-PRD.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] IETF TSVWG at Vancouver - Agenda Requests X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 17:58:43 -0000 If you still would like to present at the planned TSVWG meeting in Vancouver, please let the chairs know asap: * Presentation title / draft * Presenter * Presentation time - Last meeting we again received requests for a large number of drafts, so this time we plan again to focus must time on drafts that have seen recent discussion on the list (hint: If it has not been discussed on the list, then it probably isn't ready for tsvwg) and those drafts that have changed significantly since the last meeting. - Time for WG drafts will be allocated in precedence of other presentations. Best wishes, Gorry, James, and David --- Working Agenda below --- The working agenda is below, slots marked ??? have not been assigned a presentation and may be removed if the need for time is not confirmed. -- TSVWG Agenda IETF-87, Berlin WG Chairs: Gorry Fairhurst James Polk David Black Please note there are 2 sessions and some drafts may need to be moved between sessions to accommodate time keeping. TSVWG Session 1 0900-1130 MONDAY, July 29, 2013 Note Taker: ??? 1) Chairs (10) NOTE WELL Document Status and Accomplishments Charter & Milestones Review 2) Chairs - Drafts Under review for publication (5) 2.1) Bob/Jukka - Byte and Packet Congestion Notification (0) draft-ietf-tsvwg-byte-pkt-congest - On agenda of 2013-10-24 IESG telechat 2.2) Randy and Michael - SCTP SACK Immediately (0) draft-ietf-tsvwg-sctp-sack-immediately - TRFC Ed Queue 3) Working Group Drafts 3.1) Joe Touch (proxy Gorry Fairhurst) - Recommendations for Transport Port Uses (???) draft-ietf-tsvwg-port-use 3.2) Randy and Michael - SCTP NAT Support (??) draft-ietf-tsvwg-natsupp - Thought ready for WGLC. 3.3) James Polk - RSVP Application-ID Profiles (???) draft-ietf-tsvwg-rsvp-app-id-vv-profiles - Thought ready for WGLC. 3.4)Anurag Bhargava - RSVP for PCN (???) draft-ietf-tsvwg-rsvp-pcn - Awaiting author update 3.5) Randy and Michael - DTLS Encap of SCTP for RTCWEB (???) draft-ietf-tsvwg-sctp-dtls-encaps 3.6) SCTP Failover (???) draft-ietf-tsvwg-sctp-failover 4) Other Drafts 4.1) Edward Crabbe - Generic UDP Encapsulation for IP Tunneling (???) draft-yong-tsvwg-gre-in-udp-encap - Proposed as a work item ================================================================== ----------------------------------------------------------------- From Ruediger.Geib@telekom.de Fri Oct 18 01:28:21 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913EE11E8108 for ; Fri, 18 Oct 2013 01:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyDUxYcnifXZ for ; Fri, 18 Oct 2013 01:28:16 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 7156F21F9EFE for ; Fri, 18 Oct 2013 01:28:14 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 18 Oct 2013 10:28:11 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.46]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 18 Oct 2013 10:28:12 +0200 From: To: , , Date: Fri, 18 Oct 2013 10:28:12 +0200 Thread-Topic: New Version Notification for draft-geib-tsvwg-diffserv-intercon-04.txt Thread-Index: Ac7L26KmGQQi5YZ1Qf21bCFbP6zB7QAABNjg Message-ID: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: [tsvwg] FW: New Version Notification for draft-geib-tsvwg-diffserv-intercon-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 08:28:21 -0000 Dear TSVers I've updated my draft on terminology and on treatment of Network Control traffic at carrier interconnection interfaces. Regards, Ruediger -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, October 18, 2013 10:25 AM To: Geib, R=FCdiger; Geib, R=FCdiger Subject: New Version Notification for draft-geib-tsvwg-diffserv-intercon-04= .txt A new version of I-D, draft-geib-tsvwg-diffserv-intercon-04.txt has been successfully submitted by Ruediger Geib and posted to the IETF repository. Filename: draft-geib-tsvwg-diffserv-intercon Revision: 04 Title: DiffServ interconnection classes and practice Creation date: 2013-10-18 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-geib-tsvwg-diffs= erv-intercon-04.txt Status: http://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-= intercon Htmlized: http://tools.ietf.org/html/draft-geib-tsvwg-diffserv-inter= con-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-geib-tsvwg-diffse= rv-intercon-04 Abstract: This document proposes a limited set of interconnection QoS PHBs and PHB groups. It further introduces some DiffServ deployment aspects. The proposals made here should be integrated into a revised version of RFC5127. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From paul.hoffman@vpnc.org Sat Oct 19 07:20:55 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0D311E81A9 for ; Sat, 19 Oct 2013 07:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPWEev-yfwbf for ; Sat, 19 Oct 2013 07:20:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F112A11E81D7 for ; Sat, 19 Oct 2013 07:20:53 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9JEKpwA091161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 19 Oct 2013 07:20:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 19 Oct 2013 07:20:52 -0700 References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> To: tsvwg@ietf.org Message-Id: <98AFA638-F5C8-474F-86DE-FDDABCA04AFC@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [tsvwg] Fwd: [IPsec] Beginning of WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 14:20:55 -0000 Greetings. The IPsecME WG has started WG Last Call on a draft that deals = with IKEv2 fragmentation. The abstract says: This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The WG welcomes document reviews from anyone on this list, particularly = those who have an interest in fragmentation. Begin forwarded message: > From: Paul Hoffman > Subject: [IPsec] Beginning of WG Last Call on = draft-ietf-ipsecme-ikev2-fragmentation > Date: October 18, 2013 6:49:43 PM PDT > To: "ipsec@ietf.org WG" >=20 > Greetings again. The WG's draft on IKEv2 fragmentation has gotten a = fair amount of review in the past few months, and is thus ready for a = two-week WG Last Call (ending November 1). The draft is at: >=20 > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation >=20 > Please read this draft and send any comments to the WG mailing list, = even if the comments are "I see no problems". Comments such as "I do not = understand this part" or "this part could be explained better in this = way" are particularly useful at this point. >=20 > If you have an IKEv2 implementation, or are using someone else's IKEv2 = implementation in your products, you really should be reviewing and = commenting on this draft. This will have a significant impact on IKEv2 = implementations in the future, and having anything wrong or even unclear = in the draft will make everyone's life worse. Please do a review and = send any comments to the list. >=20 > --Paul Hoffman From internet-drafts@ietf.org Sun Oct 20 10:51:07 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A3511E822D; Sun, 20 Oct 2013 10:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M43iaE0hFI2a; Sun, 20 Oct 2013 10:51:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 958F311E8243; Sun, 20 Oct 2013 10:51:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131020175104.22753.89741.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 10:51:04 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 17:51:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Generic Aggregation of Resource ReSerVation Protocol (RS= VP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-07.txt Pages : 31 Date : 2013-10-20 Abstract: This document specifies extensions to Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From karagian@cs.utwente.nl Sun Oct 20 11:02:26 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F7811E83BD for ; Sun, 20 Oct 2013 11:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV10x-3ke0WR for ; Sun, 20 Oct 2013 11:02:21 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id C5B1911E822A for ; Sun, 20 Oct 2013 11:02:20 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sun, 20 Oct 2013 20:02:24 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.67]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Sun, 20 Oct 2013 20:02:18 +0200 From: To: , Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-07.txt Thread-Index: AQHOzb0LxfEOI6bC/0+e8s8NPIXTTZn93rn5gAAC2Sc= Date: Sun, 20 Oct 2013 18:02:18 +0000 Message-ID: References: <20131020175104.22753.89741.idtracker@ietfa.amsl.com> In-Reply-To: <20131020175104.22753.89741.idtracker@ietfa.amsl.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3F104AEXMBX23adutwent_" MIME-Version: 1.0 Cc: anuragb@cisco.com Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 18:02:26 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3F104AEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Please note that a new version of the draft-ietf-tsvwg-rsvp-pcn has been su= bmitted! http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-07.txt A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-07 We have worked out the comments that have been posted by Francois during th= e WGLC on this draft. In particular, we have addressed the following comments: o) clarify the split of functionality between PCN-ingress-node (Aggregator)= and PCN-egress-node (Deaggregator) Note that this was a signifficant change! o) *** section 1.1: expand the PBAC acronym in Introduction o) ***section 1.2: OLD: "This is also the reason of choosing Approach (1)" NEW: "This is the reason for choosing Approach (1)" o) *** section 6: expand the text to indicate to IANA that they need to allocate all the C-Ty= pes defined in section 4.1 and indicate the policy for allocating addition= al C-Types. Doing that we also updated Section 4.1. o) *** Add an example message flow in an Appendix, similar to Appendix A of= RFC4860. This considerably helps getting the general idea in a short time. Best regards, Georgios ________________________________ Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens internet-drafts= @ietf.org [internet-drafts@ietf.org] Verzonden: zondag 20 oktober 2013 19:51 To: i-d-announce@ietf.org Cc: tsvwg@ietf.org Onderwerp: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Generic Aggregation of Resource ReSerVation Proto= col (RSVP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-07.txt Pages : 31 Date : 2013-10-20 Abstract: This document specifies extensions to Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3F104AEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <96C1748BB3D7EB4CAF1180C9F7D148A7@exchange.utwente.nl> Content-Transfer-Encoding: quoted-printable

Hi all,

 

Please note that a new version of the draft-ietf-tsvwg-rsvp-pcn has been= submitted!

http://www.ietf.org/internet-drafts/draft-ietf-t= svwg-rsvp-pcn-07.txt

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp= -pcn-07


We have worked out the comments that have been posted by Francois during th= e WGLC on this draft.

 

In particular, we have addressed the following comments:

 

o) clarify the split of functionality between PCN-ingress-node (Agg= regator) and PCN-egress-node (Deaggregator)  
Note that this was a signifficant change!


o) *** section 1.1:
expand the PBAC acronym in Introduction


o) ***section 1.2:
OLD:
"This is also the reason of choosing Approach (1)"
NEW:
"This is the reason for choosing Approach (1)"


o) *** section 6:
expand the text to indicate to IANA that they need to allocate all the C-Ty= pes defined in section 4.1 and  indicate the policy for allocating add= itional C-Types. Doing that we also updated Section 4.1.



o) *** Add an example message flow in an Appendix, similar to Appendix A of= RFC4860. This considerably helps getting the general idea in a short time.=

Best regards,

Georgios

 

Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens inte= rnet-drafts@ietf.org [internet-drafts@ietf.org]
Verzonden: zondag 20 oktober 2013 19:51
To: i-d-announce@ietf.org
Cc: tsvwg@ietf.org
Onderwerp: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Transport Area Working Group Working= Group of the IETF.

        Title    &nb= sp;      : Generic Aggregation of Resource ReSerVa= tion Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains
        Author(s)    = ;   : Georgios Karagiannis
            &nb= sp;            = Anurag Bhargava
        Filename    =     : draft-ietf-tsvwg-rsvp-pcn-07.txt
        Pages    &nb= sp;      : 31
        Date    &nbs= p;       : 2013-10-20

Abstract:
   This document specifies extensions to Generic Aggregated RSVP<= br>    [RFC4860] for support of the PCN Controlled Load (CL) and Sing= le
   Marking (SM) edge behaviors over a Diffserv cloud using Pre-    Congestion Notification.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp= -pcn-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3F104AEXMBX23adutwent_-- From internet-drafts@ietf.org Sun Oct 20 11:04:19 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4421C11E8230; Sun, 20 Oct 2013 11:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7Vo087gtjaK; Sun, 20 Oct 2013 11:04:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEC711E8234; Sun, 20 Oct 2013 11:04:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131020180417.22766.12242.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 11:04:17 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 18:04:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : DTLS Encapsulation of SCTP Packets Author(s) : Michael Tuexen Randall R. Stewart Randell Jesup Salvatore Loreto Filename : draft-ietf-tsvwg-sctp-dtls-encaps-02.txt Pages : 7 Date : 2013-10-20 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-dtls-encaps-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eckelcu@cisco.com Mon Oct 21 14:07:32 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C9111E8286; Mon, 21 Oct 2013 14:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcns4gCjV14I; Mon, 21 Oct 2013 14:07:27 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5ED11E81FD; Mon, 21 Oct 2013 14:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2465; q=dns/txt; s=iport; t=1382389647; x=1383599247; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=SFAJ404aVJ5xesG+9OmZjgCrh5oJxsdVtM94Sr7kYcQ=; b=ScoUUBUuMavbwBsHse5lyh51+SH/goTiJvhW+1zVrzmvyt7iiDBiYBX8 orjzA8R0NDtVEWBnIkLylItmmH04L93V4FRmFq85pFPfymJy0C4B962Li zA6+WckIJHQxqOfEoCQo+2tEIQmHzXpgAeTPTWCPvd+uwL2bZmVdsX1tH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFABOXZVKtJV2b/2dsb2JhbABZgwc4Tga+K4EwFnSCJQEBAQQ6OAUUAQgiFEIbAQYDAgQBEggBh3wBCAW6M48qOIMfgQoDmTiQWIFmgT6CKg X-IronPort-AV: E=Sophos;i="4.93,542,1378857600"; d="scan'208";a="274813452" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 21 Oct 2013 21:07:21 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9LL7LUY000725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 21:07:21 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.239]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 16:07:21 -0500 From: "Charles Eckel (eckelcu)" To: "int-area@ietf.org" , "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-eckert-intarea-flow-metadata-framework-02.txt Thread-Index: AQHOzqGI0J6t2mDD3Um91zizQafXqg== Date: Mon, 21 Oct 2013 21:07:21 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C0882805C36E0F@xmb-aln-x08.cisco.com> In-Reply-To: <20131021204527.32521.58383.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [171.68.20.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <7C4B0ECFB9D1C548AA03973872BABEB1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 21:07:32 -0000 This update of the flow metadata framework addresses feedback received regarding: 1) the relationship of this proposed framework with existing heuristic based mechanisms 2) clarification on signed/unsigned values 3) change of delay tolerance and loss tolerance attributes to be defined in terms of a discrete and ordered set of values 4) addition of jitter tolerance attribute We did not have time to adequately expand on the security considerations, so it is being kept on the todo list for the next revision. The previous version of the draft was presented in INTAREA during IETF 87. A slot has been requested in TSVWG at IETF 88 to present "Flow Metadata Signaling with RSVP" (http://tools.ietf.org/id/draft-zamfir-tsvwg-flow-metadata-rsvp), which applies this framework to RSVP. Please have a look and and share your comments. Cheers, Charles On 10/21/13 1:45 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-eckert-intarea-flow-metadata-framework-02.txt >has been successfully submitted by Toerless Eckert and posted to the >IETF repository. > >Filename: draft-eckert-intarea-flow-metadata-framework >Revision: 02 >Title: A Framework for Signaling Flow Characteristics between >Applications and the Network >Creation date: 2013-10-21 >Group: Individual Submission >Number of pages: 18 >URL: =20 >http://www.ietf.org/internet-drafts/draft-eckert-intarea-flow-metadata-fra >mework-02.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-eckert-intarea-flow-metadata-framewo >rk >Htmlized: =20 >http://tools.ietf.org/html/draft-eckert-intarea-flow-metadata-framework-02 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-eckert-intarea-flow-metadata-fram= ew >ork-02 > >Abstract: > This document provides a framework for communicating information > elements (a.k.a. metadata) in a consistent manner between > applications and the network to provide better visibility of > application flows, thereby enabling differentiated treatment of those > flows. These information elements can be conveyed using various > signaling protocols, including PCP, RSVP, and STUN. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From internet-drafts@ietf.org Mon Oct 21 15:59:18 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0CA11E87F8; Mon, 21 Oct 2013 15:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6iU3wtNqqyb; Mon, 21 Oct 2013 15:59:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B47411E87EF; Mon, 21 Oct 2013 15:59:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021225915.32534.35432.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 15:59:15 -0700 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-failover-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:59:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Quick Failover Algorithm in SCTP Author(s) : Yoshifumi Nishida Preethi Natarajan Armando Caro Paul D. Amer Filename : draft-ietf-tsvwg-sctp-failover-02.txt Pages : 17 Date : 2013-10-21 Abstract: One of the major advantages in SCTP is supporting multi-homing communication. If a multi-homed end-point has redundant network connections, SCTP sessions can have a good chance to survive from network failures by migrating inactive network to active one. However, if we follow the SCTP standard, there can be significant delay for the network migration. During this migration period, SCTP cannot transmit much data to the destination. This issue drastically impairs the usability of SCTP in some situations. This memo describes the issue of SCTP failover mechanism and discuss its solutions which require minimal modification to the current standard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-failover There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-failover-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-failover-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bob.briscoe@bt.com Mon Oct 21 16:41:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E990711E8834; Mon, 21 Oct 2013 16:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOniafac-Zzd; Mon, 21 Oct 2013 16:41:25 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8F91311E8837; Mon, 21 Oct 2013 16:40:49 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 22 Oct 2013 00:40:41 +0100 Received: from EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 22 Oct 2013 00:40:42 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR02-UKIP.domain1.systemhost.net (147.149.100.81) with Microsoft SMTP Server id 14.2.347.0; Tue, 22 Oct 2013 00:40:41 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.109.40.34]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9LNee5p025162; Tue, 22 Oct 2013 00:40:40 +0100 Message-ID: <201310212340.r9LNee5p025162@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Oct 2013 00:40:39 +0100 To: Dave Taht From: Bob Briscoe In-Reply-To: References: <201309171233.r8HCXKkV003952@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "aqm@ietf.org" , tsvwg IETF list Subject: [tsvwg] Immediate and Explicit Congestion Notification (was: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:41:30 -0000 Dave, Thx for cross-posting. It's quite possible there are aqm people not on= tsvwg. 1) Did you have views on the ecn-encap-guidelines I-D itself? Is it helpful? I think it's fairly non-controversial. 2) In case I'm misunderstood, I don't see much=20 latency gain from ECN as currently defined=20 (RFC3168). I'm still banging on about ECN in=20 lower layers 'cos early tests show promise that=20 we may have found a way to make the ultra-low=20 queuing delay of data centre TCP incrementally=20 deployable on the public Internet We =3D Mirja Kuehlewind, David Wagner, Juan Manuel Reyes Espinosa= and I. It can be deployed with most existing kit,=20 without any new AQM implementation needed. We use=20 WRED in an unusual configuration. The idea in a nutshell: * For ECN-capable packets, shift the job of hiding bursts from network to= host: - ECN-capable packets map to a WRED policy with queue smoothing turned= off - so the network signals ECN with zero smoothing delay - then the transport can hide bursts of ECN=20 signals from itself (like DCTCP does) - the transport knows o that it's ECN-capable o whether it's TCP or RTP etc, o whether its in congestion avoidance or slow-start, o and it knows its RTT, o so it can know whether to respond immediately or to smooth the= signals, o and if so, over what time - then short RTT flows can smooth the signals=20 with only the delay of their /own/ RTT o so they can fill troughs and absorb peaks that longer RTT flows= cannot - a TCP only needs to smooth the signals if in congestion avoidance o in slow start, it can respond immediately, thus reducing overshoot There's more to it - I've asked to present the whole story in Vancouver. Bob At 05:35 15/10/2013, Dave Taht wrote: >It is my general assumption that membership in the aqm wg is a subset >of tsvwg, but in case it isn't... > > >---------- Forwarded message ---------- >From: Bob Briscoe >Date: Tue, Sep 17, 2013 at 5:33 AM >Subject: [tsvwg] Guidelines for Adding Congestion Notification to >Protocols that Encapsulate IP >To: tsvwg IETF list >Cc: Gorry Fairhurst > > >TSV folks, > >We've just posted an update to the guidelines for adding congestion >notification to L2 and tunnelling protocols, e.g. Ethernet, L2TP, GRE, >PPTP, GTP etc. Especially of current interest in mobile and separately >in data centres. > >Pls read/review and send any comments to the list. > > >It's currently still an individual draft; intended status: BCP. >We're looking for support for adoption as a item of work in tsvwg. > >We've dealt with most of the outstanding issues from previous reviews, >esp. those from Gorry (see summary of diffs below). > >-------------------------------- >Summary of Diffs from -02 to -03 > > * Scope section: > > + Added dependence on correct propagation of traffic class > information > > + For the feed-backward mode, deemed multicast and anycast out > of scope > > * Ensured all guidelines referring to subnet technologies also > refer to tunnels and vice versa by adding applicability > sentences at the start of sections 4.1, 4.2, 4.3, 4.4, 4.6 and > 5. > > * Added Security Considerations on ensuring congestion signal > fields are classed as immutable and on using end-to-end > congestion signal integrity technologies rather than hop-by- > hop. > > >Bob > > > > From: > > To: John Kaippallimalil , > > Bob Briscoe > > , > > "Bob J.Briscoe" , > > Pat Thaler > > , > > Patricia Thaler > > Subject: New Version Notification for > > draft-briscoe-tsvwg-ecn-encap-guidelines-03.txt > > > > > > A new version of I-D, draft-briscoe-tsvwg-ecn-encap-guidelines-03.txt > > has been successfully submitted by Bob Briscoe and posted to the > > IETF repository. > > > > Filename: draft-briscoe-tsvwg-ecn-encap-guidelines > > Revision: 03 > > Title: Guidelines for Adding=20 > Congestion Notification to Protocols that Encapsulate IP > > Creation date: 2013-09-17 > > Group: Individual Submission > > Number of pages: 29 > > URL:=20 >= http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-ecn-encap-guideline= s-03.txt > > Status:=20 > http://datatracker.ietf.org/doc/draft-briscoe-tsvwg-ecn-encap-guidelines > > Htmlized:=20 > http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines-03 > > Diff:=20 >= http://www.ietf.org/rfcdiff?url2=3Ddraft-briscoe-tsvwg-ecn-encap-guidelines= -03 > > > > Abstract: > > The purpose of this document is to guide the design of congestion > > notification in any lower layer or tunnelling protocol that > > encapsulates IP. The aim is for explicit congestion signals to > > propagate consistently from lower layer protocols into IP. Then the > > IP internetwork layer can act as a portability layer to carry > > congestion notification from non-IP-aware congested nodes up to the > > transport layer (L4). Following these guidelines should assure > > interworking between new lower layer congestion notification > > mechanisms, whether specified by the IETF or other standards bodies. > > > > > > > > > > > > Please note that it may take a couple of=20 > minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > >________________________________________________________________ >Bob Briscoe, BT > > >-- >Dave T=E4ht > >Fixing bufferbloat with cerowrt:=20 >http://www.teklibre.com/cerowrt/subscribe.html >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT=20 From touch@isi.edu Mon Oct 21 17:06:52 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FD411E87A7; Mon, 21 Oct 2013 17:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mns1sNJGay2c; Mon, 21 Oct 2013 17:06:47 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1BB11E8771; Mon, 21 Oct 2013 17:06:46 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9M06DeV005272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Oct 2013 17:06:17 -0700 (PDT) Message-ID: <5265C19B.30108@isi.edu> Date: Mon, 21 Oct 2013 17:06:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, "tsv-ads@tools.ietf.org" , tsvwg References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> In-Reply-To: <523CB9CB.7060507@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-dir@ietf.org" Subject: [tsvwg] TSVDIR-ish review of draft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 00:06:53 -0000 Hi, all, I've reviewed the following doc for TSVDIR: draft-ietf-ipsecme-ikev2-fragmentation-04 Although this is not intended as a complete TSVDIR review, I have checked for the typical issues. Joe ------------------------------------------------------------------- draft-ietf-ipsecme-ikev2-fragmentation-04 This doc makes the case that IKEv2 should implement its own frag/reassembly mechanism, because some NATs don't pass IP fragments. First, the issue with NATs and fragments should be made more clear, especially citing existing descriptions of this issue, e.g., RFC4787. Note that NATs which do not pass fragments violate RFQ-14 of that BCP RFC, and it might be useful to report this issue to the vendor. Second, it is not clear why this issue is being handled inside IKE. Appendix A provides a design rationale, but it clearly trades computation and space overhead for local storage, and still permits DOS attacks (e.g., overloading the receiver with false fragments). An equally viable solution (see ** below) would involve placing a single signed IKE message into a single IP packet, fragmenting that packet, and transmitting those fragments inside UDP datagrams. This approach could use the innermost IP encapsulation as the reassembly layer. **: Although this approach is susceptible to fragmentation overload, so too is transmitting the original message over IP that is naturally fragmented at the network layer anyway - this introducing no new vulnerability. This IP-encapsulated IKE message would need the same negotiation described in section 2.3, but would avoid the complexity of most of the rest of the document, relying instead on existing IP reassembly. In conclusion, I don't see the need for the level of detail and mechanism proscribed, basically because it reinvents the wheel, but see no other substantial issues with it. Additionally, regarding PMTUD, this should be done using PLMTUD (RFC 4821), and should be described as such. --- From touch@isi.edu Mon Oct 21 17:26:50 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEF111E82CD; Mon, 21 Oct 2013 17:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.377 X-Spam-Level: X-Spam-Status: No, score=-104.377 tagged_above=-999 required=5 tests=[AWL=-1.778, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+vno1XR6GBs; Mon, 21 Oct 2013 17:26:44 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 888BF11E82C4; Mon, 21 Oct 2013 17:26:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9M0QA46010833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Oct 2013 17:26:10 -0700 (PDT) Message-ID: <5265C647.5020908@isi.edu> Date: Mon, 21 Oct 2013 17:26:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Martin Stiemerling , ipsec@ietf.org, draft-amjads-ipsecme-ikev2-data-channel@tools.ietf.org, "tsv-ads@tools.ietf.org" , tsvwg References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> In-Reply-To: <5265C19B.30108@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-dir@ietf.org" Subject: [tsvwg] TSVDIR-ish review of draft-amjads-ipsecme-ikev2-data-channel-00 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 00:26:51 -0000 Hi, all, I've reviewed the following doc for TSVDIR: draft-amjads-ipsecme-ikev2-data-channel-00 Although this is not intended as a complete TSVDIR review, I have checked for the typical issues. Joe ------------------------------------------------------------------- draft-amjads-ipsecme-ikev2-data-channel-00 This doc makes the case that IKEv2 can provide a secure data channel for arbitrary communication, rather than being used (as designed) to configure IPsec channels for that purpose. This mechanism lacks congestion control, and so needs to be used only where its load is known to be a small fraction of capacity. In specific, IKE's window mechanism allows for increasing the window size but not decreasing it, as is needed to react to network congestion. The acknowledged data transfer mode uses IKE's window mechanism, which is presumably set to a small value, and may result in very low throughput. Attempts to increase this window size to overcome this limitation can easily increase burstiness and network loss. This mechanism includes its own fragmentation mechanism based on a pre-configiured MTU, where it should use an adaptive size based on PLMTUD (RFC4821). The mechanism described replicates that of IP, and so introduces no new issues. Fragment reassembly appears to rely on the IKE sequence number, and the relationship between the two should be more clear, especially on the reuse of the IKE sequence number and how that affects reassembly timeout. --- From ford@isoc.org Tue Oct 22 03:56:25 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A89621F9E8D for ; Tue, 22 Oct 2013 03:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YbJlxpebaEN for ; Tue, 22 Oct 2013 03:56:11 -0700 (PDT) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) by ietfa.amsl.com (Postfix) with ESMTP id BC40911E8354 for ; Tue, 22 Oct 2013 03:56:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3F996601CE; Tue, 22 Oct 2013 06:56:07 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp1.relay.iad3a.emailsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 568276056D; Tue, 22 Oct 2013 06:56:06 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Matthew Ford In-Reply-To: <201310212340.r9LNee5p025162@bagheera.jungle.bt.co.uk> Date: Tue, 22 Oct 2013 11:56:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <657D1484-1B02-41F5-9FD1-0921439DF754@isoc.org> References: <201309171233.r8HCXKkV003952@bagheera.jungle.bt.co.uk> <201310212340.r9LNee5p025162@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1510) Cc: tsvwg IETF list , "aqm@ietf.org" Subject: Re: [tsvwg] [aqm] Immediate and Explicit Congestion Notification (was: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 10:56:28 -0000 On 22 Oct 2013, at 00:40, Bob Briscoe wrote: > There's more to it - I've asked to present the whole story in = Vancouver. Cool, looking forward to it. I'll prime the question pump now if I may: Does the transport need to know that it is connected to a network that = will signal ECN in this fashion? Mat From touch@isi.edu Tue Oct 22 08:28:14 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7AB11E83FA; Tue, 22 Oct 2013 08:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLKZTa0ieD4h; Tue, 22 Oct 2013 08:28:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5311E84C1; Tue, 22 Oct 2013 08:28:08 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9MFRQrG018461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Oct 2013 08:27:39 -0700 (PDT) Message-ID: <52669960.1000706@isi.edu> Date: Tue, 22 Oct 2013 08:27:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> In-Reply-To: <14DB3765679C45D283869DC9010F0084@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 15:28:14 -0000 Hi, Valery, On 10/22/2013 5:50 AM, Valery Smyslov wrote: > Hi Joe, > > thank you for your review. > Please, see my comments inline. > >> Hi, all, >> >> I've reviewed the following doc for TSVDIR: >> draft-ietf-ipsecme-ikev2-fragmentation-04 >> >> Although this is not intended as a complete TSVDIR review, I have >> checked for the typical issues. >> >> Joe >> >> ------------------------------------------------------------------- >> >> draft-ietf-ipsecme-ikev2-fragmentation-04 >> >> This doc makes the case that IKEv2 should implement its own >> frag/reassembly mechanism, because some NATs don't pass IP fragments. >> >> First, the issue with NATs and fragments should be made more clear, >> especially citing existing descriptions of this issue, e.g., RFC4787. >> Note that NATs which do not pass fragments violate RFQ-14 of that BCP >> RFC, and it might be useful to report this issue to the vendor. >> >> Second, it is not clear why this issue is being handled inside IKE. >> Appendix A provides a design rationale, but it clearly trades >> computation and space overhead for local storage, and still permits DOS > > I don't see a strict computation/memory tradeoff here. You must > verify message validity in any case, whether it is done before > reassempling (on each fragment), or after it is complete (including > the case when you get garbage message due to false fragments). > The amount of consumped CPU power will be roughly the same. The cost to verify several individual messages is higher than the cost to verify a single message, especially when the individual messages are not exactly the blocksize of the algorithm used. So in the case of no attack, the overhead of your proposed mechanism is higher. You can't drop an entire message when a single false fragment arrives, because there could be other valid fragments on the way. So either way you end up checking the same amount of data, but your computational overhead is higher. > But the amount of memory consumption will be smaller if > you are able to discard false fragments. Yes, but you also need to keep some state about pending partial valid messages. AFAICT, the memory difference is more likely to be negligible, but the processing difference high. >> attacks (e.g., overloading the receiver with false fragments). > > This attack is always possible both with and without fragmentation > (just overloading with false full messages) and IKE is designed to > withstand it. > Handling fragmentation in IKE doesn't make it more vulnerable to this > attack. > On the other hand, handling fragmentation outside IKE (on IP level) > or using unauthenticated fragments in IKE, makes it susceptible to an > attack, > described in the rationale, i.e. when attacker spending virtually zero > resources > can stop IKE communication by infrequently injecting bad fragments, > which results in "poisoning" of reassembling queue. Using authenticated > fragments > prevents this kind of attack. Avoiding fragmentation poisoning attacks is not a motivation of this work. If you want to make that case, you need to explain why you think that is a significant issue and worth the effort to fix inside IKE. Further, this method does not necessarily avoid IP fragmentation. Fragments are supposed to pass through a NAT (see my previous reference), and when they do your mechanism wouldn't adjust the IKE size downward. >> An equally viable solution (see ** below) would involve placing a >> single signed IKE message into a single IP packet, fragmenting that >> packet, and transmitting those fragments inside UDP datagrams. This >> approach could use the innermost IP encapsulation as the reassembly >> layer. >> >> **: Although this approach is susceptible to fragmentation overload, >> so too is transmitting the original message over IP that is naturally >> fragmented at the network layer anyway - this introducing no new >> vulnerability. > > But using IKE fragmentation in this case might eliminate this > vulnerability. It might, but again that's not your threat model and there are other vulnerabilities this method opens up (e.g., replay attacks have a higher CPU impact). >> This IP-encapsulated IKE message would need the same negotiation >> described in section 2.3, but would avoid the complexity of most of >> the rest of the document, relying instead on existing IP reassembly. >> >> In conclusion, I don't see the need for the level of detail and >> mechanism proscribed, basically because it reinvents the wheel, but >> see no other substantial issues with it. >> >> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC >> 4821), and should be described as such. > > IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based > and RFC4821 has many restrictions when used with connectionless > datagram protocols, some of which are often difficult to satisfy in > environments, > where IKE is used. You are re-inventing PLMUTD. In places where you claim RFC4821 is too complex - those are the places where your mechanism is deficient IMO. E.g., positive verification that a message gets through as a confirmation of when you've achieved a reasonable size. > Second, the goal of PLMTUD is to find _maximum_ > MTU size that is not fragmented by IP, in other words, to maximize > throughput. For IKE the goal of PMTUD is to find _any_reasonable_ > MTU size that won't be fragmented by IP. Throughput is not important. Agreed, but if that's the case, why not always send the smallest possible message size (68 bytes)? It's because the overhead is too high (additional headers, blocksize mismatch, and computational startup cost on each block). Further, most transports don't care about 1400 vs. 1500 bytes; they're searching for a rough approximation of a 'large' packet, as are you IMO. > Third, PMTU discovery in the draft is completely optional and one may > use any other mechanisms (including PLMTUD, if it is available) > to obtain MTU information. The transport folks spent a lot of time on PLMTUD; there are a lot of lessons there that can and should be applied here. PLMTUD is already flexible enough to apply here directly. You can always reinvent the wheel, of course. Joe From brian.e.carpenter@gmail.com Tue Oct 22 16:57:12 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3630D11E829E for ; Tue, 22 Oct 2013 16:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.413 X-Spam-Level: X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL9A24T+BagE for ; Tue, 22 Oct 2013 16:57:11 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF6D11E822E for ; Tue, 22 Oct 2013 16:57:11 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id bj1so223186pad.14 for ; Tue, 22 Oct 2013 16:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nyZ2mrqmo8iPGIDeA2NGVa+if/YGE9jcrfIL7OhFTTQ=; b=UTjDXx/g4UqGpzkwvR5NVbCSTDhGrvSkjXU2lI9ldbsoWY0HXNCl2mnQM8LMjtoZCA Lq0kyQDkcaDGoKvl8CL/h4LEUhc/TxRM52eXeIexXvcOaP3e9yn/zZQUQqDgOXi0x12C xPIEWRiFdLS7uWpaig9i7TrxCwTEF9mjs2a/0yoyiWf/KZqNvLoNASpuToPWwB0l+IgO RkFIjg4LwpucBF/v2fl5Od2e/MrksuanJ3BJpm652a2vBfAHS3NI060TKOIbFZWB7hGC PasDZamcmc6jRrTG7CXNpcJlfmVKSonS1iskmlEQBRU4l681elp8o7HVTplSH5Tp9vZs oiDw== X-Received: by 10.68.215.38 with SMTP id of6mr378309pbc.14.1382486222817; Tue, 22 Oct 2013 16:57:02 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id xe9sm36483957pab.0.2013.10.22.16.57.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 22 Oct 2013 16:57:02 -0700 (PDT) Message-ID: <526710D1.7050005@gmail.com> Date: Wed, 23 Oct 2013 12:57:05 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tsvwg@ietf.org References: <20131018082525.2295.99744.idtracker@ietfa.amsl.com> In-Reply-To: <20131018082525.2295.99744.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [tsvwg] I-D Action: draft-geib-tsvwg-diffserv-intercon-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 23:57:12 -0000 Hi R=C3=BCdiger, > DSCP Precedence Prefix The bits 0-2 of the DSCP (marked "x" in this= > generic DSCP field: xxxddd) are called the DSCP Precedence > Prefix [RFC2474] in the following. By ignoring the value of= > bits 3-6 ( d stands for don' care), a simple aggregation of > PHBs differed by DSCP is possible in IP and MPLS backbones, > but also if Ethernet transport is applied. =20 Thankyou for providing explicit terminology for this. I am still worried that by reviving the word "precedence" we would seriously damage outsider= s' understanding of differentiated services. The specific reason we got rid of "precedence" and the notion of simple priority (except for implementin= g the legacy code points) was to underline that precedence doesn't provide quality of service; if anything, it provides quality of disservice. Couldn't you call those three bits "DSCP Aggregation Prefix"? Then they would refer to 8 traffic classes, and only in a very primitive implementation would they be mapped to priority levels. Brian From jiangsheng@huawei.com Tue Oct 22 20:41:16 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542CA11E8116 for ; Tue, 22 Oct 2013 20:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtBeElXhbNVc for ; Tue, 22 Oct 2013 20:41:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C029611E80EC for ; Tue, 22 Oct 2013 20:41:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZI88017; Wed, 23 Oct 2013 03:41:10 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 04:41:08 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 04:41:08 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Wed, 23 Oct 2013 11:41:03 +0800 From: Sheng Jiang To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-yin-tsvwg-ipflow-pathtrace-ps-01.txt Thread-Index: AQHOzkM1qRidHIYLY0yoEPYMXDckXpoBpPxw Date: Wed, 23 Oct 2013 03:41:02 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD4C8C9@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [tsvwg] FW: New Version Notification for draft-yin-tsvwg-ipflow-pathtrace-ps-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 03:41:16 -0000 SGksIFRTVldHLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBkcmFmdCwgd2hpY2ggZGVzY3Jp YmUgdGhlIHByb2JsZW0gdGhhdCB0aGVyZSBpcyBubyB0cmFjZSByb3V0ZSBtZWNoYW5pc20gdGhh dCB3b3JrcyBpbiBJUC9NUExTIGhldGVyb2dlbmVvdXMgbmV0d29yayBlbnZpcm9ubWVudC4NCg0K VGhlIGF1dGhvcnMgd291bGQgbGlrZSB0byBnZXQgcmV2aWV3cyBieSB0aGUgV0csIHBhcnRpY3Vs YXJseSBvbiB3aGV0aGVyIHRoaXMgcHJvYmxlbSBhcmUgdmFsaWQuDQoNCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXlpbi10c3Z3Zy1pcGZsb3ctcGF0aHRyYWNlLXBzLTAxDQoNCkJl c3QgcmVnYXJkcywNCg0KU2hlbmcgKyBZdWFuYmluDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10NCj5TZW50OiBNb25kYXksIE9jdG9iZXIgMjEsIDIwMTMgNTo1MSBQTQ0K PlRvOiBZaW55dWFuYmluOyBTaGVuZyBKaWFuZzsgWWFuZ2FuZw0KPlN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC15aW4tdHN2d2ctaXBmbG93LXBhdGh0cmFjZS1w cy0wMS50eHQNCj4NCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteWluLXRzdndnLWlw Zmxvdy1wYXRodHJhY2UtcHMtMDEudHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBZdWFuYmluIFlpbiBhbmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4N Cj5GaWxlbmFtZToJIGRyYWZ0LXlpbi10c3Z3Zy1pcGZsb3ctcGF0aHRyYWNlLXBzDQo+UmV2aXNp b246CSAwMQ0KPlRpdGxlOgkJIElQIEZsb3cgUGF0aCBUcmFjZSBSZXF1aXJlbWVudHMNCj5DcmVh dGlvbiBkYXRlOgkgMjAxMy0xMC0yMQ0KPkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K Pk51bWJlciBvZiBwYWdlczogOA0KPlVSTDoNCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC15aW4tdHN2d2ctaXBmbG93LXBhdGh0cmFjZS1wcy0wMS50DQo+eHQNCj5T dGF0dXM6DQo+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC15aW4tdHN2d2ct aXBmbG93LXBhdGh0cmFjZS1wcw0KPkh0bWxpemVkOg0KPmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXlpbi10c3Z3Zy1pcGZsb3ctcGF0aHRyYWNlLXBzLTAxDQo+RGlmZjoNCj5odHRw Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC15aW4tdHN2d2ctaXBmbG93LXBhdGh0 cmFjZS1wcy0wMQ0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRo ZSByZXF1aXJlbWVudHMgb2YgSVAgZmxvdyBwYXRoIHRyYWNlLg0KPiAgIE5ldHdvcmsgYWRtaW5p c3RyYXRvcnMgbmVlZCB0byBnZXQgdGhlIHJlYWwgSVAgZmxvdyBwYXRoIGluZm9ybWF0aW9uLA0K PiAgIG9mIHdoaWNoIGEgc3BlY2lmaWMgSVAgZmxvdyBnb2VzIHRocm91Z2ggaGV0ZXJvZ2VuZW91 cyBuZXR3b3JrDQo+ICAgZW52aXJvbm1lbnRzLiAgSXQgaXMgYWxzbyBkZXNpcmVkIGZvciBtb3Jl IGluZm9ybWF0aW9uIHJlbGV2YW50IHRvDQo+ICAgdGhlIElQIGZsb3cgcGF0aC4gIEJhc2VkIG9u IHRoZSBpbmZvcm1hdGlvbiwgbmV0d29yayBhZG1pbmlzdHJhdG9ycw0KPiAgIGNhbiBsb2NhdGUg cG9zc2libGUgZmF1bHRzIG9mIHRoZSBuZXR3b3JrIHF1aWNrbHkgb3Igb3B0aW1pemUgbmV0d29y aw0KPiAgIHJlc291cmNlIGZvciBiZXR0ZXIgbmV0d29yayBwZXJmb3JtYW5jZS4NCj4NCj4NCj4N Cj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQo= From svanru@gmail.com Tue Oct 22 05:51:05 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A1911E819F; Tue, 22 Oct 2013 05:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnpuOcSw5Tc1; Tue, 22 Oct 2013 05:51:04 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD9911E838F; Tue, 22 Oct 2013 05:51:00 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id u14so3601339lbd.36 for ; Tue, 22 Oct 2013 05:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=5u3TNbhTmQENnl6oJV+UPDmywtTqX6VY4vtmmQPkAaI=; b=RYMSL55EI2br11ZX2e/q4RDahBkJ14M2rGycu6uyRCLCzQBSVJmEw2Xm0q9pbSP6xQ cYiMxnTVf9UFsii5QtIL/EXTTKqSfZHCSV7d4h0Ew2ssWGBu6XgdtSWuX2+RTazzGKLn FhQVWafmv9G9tU/KwtIz8c8qkc5d0gPs7I45jZyvSje3abPO1v752YXzM6XoOVZmy9HH IvUWdz4SCHkkH/Hj5IjwlfjV//AGC6T8ADfmBSwVmgxMQWRGXlbS9ekc5lJeXnkUBv4o Ezi8t9y5vuKKcsZwS08tWVaJ43vBZ6cK9Dk4WbQIzVH6Rx+5TrCKLU5ISJZa5gQQhEFi IXgg== X-Received: by 10.152.235.40 with SMTP id uj8mr1647796lac.39.1382446259216; Tue, 22 Oct 2013 05:50:59 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id kx1sm20944084lac.7.2013.10.22.05.50.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Oct 2013 05:50:58 -0700 (PDT) Message-ID: <14DB3765679C45D283869DC9010F0084@buildpc> From: "Valery Smyslov" To: "Joe Touch" , "Martin Stiemerling" , , , , "tsvwg" References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> Date: Tue, 22 Oct 2013 16:50:57 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Wed, 23 Oct 2013 03:56:27 -0700 Cc: tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 12:51:05 -0000 Hi Joe, thank you for your review. Please, see my comments inline. > Hi, all, > > I've reviewed the following doc for TSVDIR: > draft-ietf-ipsecme-ikev2-fragmentation-04 > > Although this is not intended as a complete TSVDIR review, I have checked > for the typical issues. > > Joe > > ------------------------------------------------------------------- > > draft-ietf-ipsecme-ikev2-fragmentation-04 > > This doc makes the case that IKEv2 should implement its own > frag/reassembly mechanism, because some NATs don't pass IP fragments. > > First, the issue with NATs and fragments should be made more clear, > especially citing existing descriptions of this issue, e.g., RFC4787. Note > that NATs which do not pass fragments violate RFQ-14 of that BCP RFC, and > it might be useful to report this issue to the vendor. > > Second, it is not clear why this issue is being handled inside IKE. > Appendix A provides a design rationale, but it clearly trades computation > and space overhead for local storage, and still permits DOS I don't see a strict computation/memory tradeoff here. You must verify message validity in any case, whether it is done before reassempling (on each fragment), or after it is complete (including the case when you get garbage message due to false fragments). The amount of consumped CPU power will be roughly the same. But the amount of memory consumption will be smaller if you are able to discard false fragments. > attacks (e.g., overloading the receiver with false fragments). This attack is always possible both with and without fragmentation (just overloading with false full messages) and IKE is designed to withstand it. Handling fragmentation in IKE doesn't make it more vulnerable to this attack. On the other hand, handling fragmentation outside IKE (on IP level) or using unauthenticated fragments in IKE, makes it susceptible to an attack, described in the rationale, i.e. when attacker spending virtually zero resources can stop IKE communication by infrequently injecting bad fragments, which results in "poisoning" of reassembling queue. Using authenticated fragments prevents this kind of attack. > An equally viable solution (see ** below) would involve placing a single > signed IKE message into a single IP packet, fragmenting that packet, and > transmitting those fragments inside UDP datagrams. This approach could use > the innermost IP encapsulation as the reassembly layer. > > **: Although this approach is susceptible to fragmentation overload, so > too is transmitting the original message over IP that is naturally > fragmented at the network layer anyway - this introducing no new > vulnerability. But using IKE fragmentation in this case might eliminate this vulnerability. > This IP-encapsulated IKE message would need the same negotiation described > in section 2.3, but would avoid the complexity of most of the rest of the > document, relying instead on existing IP reassembly. > > In conclusion, I don't see the need for the level of detail and mechanism > proscribed, basically because it reinvents the wheel, but see no other > substantial issues with it. > > Additionally, regarding PMTUD, this should be done using PLMTUD (RFC > 4821), and should be described as such. IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based and RFC4821 has many restrictions when used with connectionless datagram protocols, some of which are often difficult to satisfy in environments, where IKE is used. Second, the goal of PLMTUD is to find _maximum_ MTU size that is not fragmented by IP, in other words, to maximize throughput. For IKE the goal of PMTUD is to find _any_reasonable_ MTU size that won't be fragmented by IP. Throughput is not important. Third, PMTU discovery in the draft is completely optional and one may use any other mechanisms (including PLMTUD, if it is available) to obtain MTU information. Thanks, Valery Smyslov. From paul@cypherpunks.ca Tue Oct 22 08:35:49 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36F511E84B4; Tue, 22 Oct 2013 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqtc2bs5mNzH; Tue, 22 Oct 2013 08:35:44 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 231E811E84A4; Tue, 22 Oct 2013 08:35:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d3zLY13Wvz1Kk; Tue, 22 Oct 2013 11:35:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id rhuLavDercs3; Tue, 22 Oct 2013 11:35:15 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 22 Oct 2013 11:35:14 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 5A147807CA; Tue, 22 Oct 2013 11:35:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4E0D3805BD; Tue, 22 Oct 2013 11:35:13 -0400 (EDT) Date: Tue, 22 Oct 2013 11:35:13 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Valery Smyslov In-Reply-To: <14DB3765679C45D283869DC9010F0084@buildpc> Message-ID: References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Wed, 23 Oct 2013 03:56:34 -0700 Cc: "ipsec@ietf.org WG" , tsv-ads@tools.ietf.org, tsvwg Subject: Re: [tsvwg] [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 15:35:50 -0000 On Tue, 22 Oct 2013, Valery Smyslov wrote: >> attacks (e.g., overloading the receiver with false fragments). > > This attack is always possible both with and without fragmentation > (just overloading with false full messages) and IKE is designed to withstand > it. Partially. For unfragmented IKE, the cookies/SPI mitigate this if you give preference to IKE messages further in the processing queue. With this draft, I'm forced to do more crypto on IKE packets before I can decide if these need prioritization or not (with the exception of the first packet, which cannot get fragmented anyway) > Handling fragmentation in IKE doesn't make it more vulnerable to this attack. Handling encrypted fragments does, because you will spend more time doing the crypto. Although this still happens after the cookie/spi verification. You are doing an additional round of crypto on each fragment in addition to the regular IKE crypto you need to perform on the assembled packet. Fragments could be made artificially long and the IKE packet artificial big, resulting in much more crypto. Now I think this might not matter much, because the attacker needs to be local and they will only be local to a remote endpoint which has enough CPU, not the ipsec core gateway that actually might run out of CPU power when under attack. > On the other hand, handling fragmentation outside IKE (on IP level) > or using unauthenticated fragments in IKE, makes it susceptible to an attack, > described in the rationale, i.e. when attacker spending virtually zero > resources > can stop IKE communication by infrequently injecting bad fragments, > which results in "poisoning" of reassembling queue. But the attack is theoretical and of no practical value. 1) on-path attacker (remote) They can just DOS you regardless by withholding packets. 2) off-path attacker (remote) These attackers don't know the cookies/spi's so they can't really sent a forged fragment you would use for assembly - protected with crypto or not. It is also impossible for them to time their attack so that one of their fragments intersect with one of your fragments so they would need to start sending fragments before the endpoint does but using mostly wrong cookies/spis and would swamp an endpoint with easilly detectable forged packets. 3) shared medium like wifi hotspot (local) These are the only attackers with enough knowledge to sent sufficiently advanced bad fragments interfering with incoming fragments. They can already do all the damage they want without resorting to IKE fragment spoofing. They can arp spoof the gateway, sent a Wifi de-association request, sent enough garbage to fill the air waves, and interfere with the IKE in such a way that you think the remote peer does not support fragmentation at all. So this draft protects against a local attacker that wants to masquerade as a network failure and only prevent you from doing IKE, hoping you will fall back to plaintext traffic. Software could notify the user that they seem to be under attack, which IMHO would be more valuable to the user than quiet resilience against the attack. > Using authenticated fragments prevents this kind of attack. Yes, it prevents one of the low hanging fruits. Which I don't think is worth the complexity of this draft compared to the existing fragmentation code out in the wild. > But using IKE fragmentation in this case might eliminate this vulnerability. At the price of adding more complexity to IKE. With the attacker not stopped from their goal. >> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC 4821), >> and should be described as such. > > IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based > and RFC4821 has many restrictions when used with connectionless > datagram protocols, some of which are often difficult to satisfy in > environments, > where IKE is used. Second, the goal of PLMTUD is to find _maximum_ > MTU size that is not fragmented by IP, in other words, to maximize > throughput. For IKE the goal of PMTUD is to find _any_reasonable_ > MTU size that won't be fragmented by IP. Throughput is not important. > Third, PMTU discovery in the draft is completely optional and one may > use any other mechanisms (including PLMTUD, if it is available) > to obtain MTU information. I agree. There is going to be like 2 to 4 fragments. Size does not matter. It's better to cut down on latency/RTT by using an MTU size that is for sure to work on the first go. But that's also why this complexity is not worth it. Fragmentation does only mean going from 1 IKE packet to 2-4 IKE packets. The timeframe to mess with these are in the 5ms range. If an attacker has that accuracy against you, you've lost already regardless. I doubt the attacker can even pull it off on wifi. The original IKE fragmentation is really nice and simple. Copy part of the original IKE header, add a single payload with fragment payload type and fragment number/max, sent fragments in a burst. This draft looks like it is fixing a security issue, while it really should be just about sending smaller packets as similar as possible to the original single packet. Messing with one IKE packet versus 2-4 IKE packets is not a real problem that I think needs fixing. Paul From svan@elvis.ru Tue Oct 22 23:26:28 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D15411E82E6; Tue, 22 Oct 2013 23:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCpwwmUVXeIl; Tue, 22 Oct 2013 23:26:21 -0700 (PDT) Received: from bull.elvis.ru (bull.elvis.ru [93.188.44.194]) by ietfa.amsl.com (Postfix) with ESMTP id D19B311E816F; Tue, 22 Oct 2013 23:25:59 -0700 (PDT) Received: from robin.office.elvis.ru ([10.111.1.40]) by bull.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1VYrsh-0002DV-3v; Wed, 23 Oct 2013 10:25:23 +0400 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.1.438.0; Wed, 23 Oct 2013 10:25:54 +0400 Message-ID: From: Valery Smyslov To: Joe Touch References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> Date: Wed, 23 Oct 2013 10:25:56 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Wed, 23 Oct 2013 03:56:34 -0700 Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 06:26:28 -0000 >>> This doc makes the case that IKEv2 should implement its own >>> frag/reassembly mechanism, because some NATs don't pass IP fragments. >>> >>> First, the issue with NATs and fragments should be made more clear, >>> especially citing existing descriptions of this issue, e.g., RFC4787. >>> Note that NATs which do not pass fragments violate RFQ-14 of that BCP >>> RFC, and it might be useful to report this issue to the vendor. >>> >>> Second, it is not clear why this issue is being handled inside IKE. >>> Appendix A provides a design rationale, but it clearly trades >>> computation and space overhead for local storage, and still permits DOS >> >> I don't see a strict computation/memory tradeoff here. You must >> verify message validity in any case, whether it is done before >> reassempling (on each fragment), or after it is complete (including >> the case when you get garbage message due to false fragments). >> The amount of consumped CPU power will be roughly the same. > > The cost to verify several individual messages is higher than the cost to > verify a single message, especially when the individual messages are not > exactly the blocksize of the algorithm used. Right. That's why I wrote "_roughly_ the same". Of course there is some overhead, not only due to blocksize, but mainly due to the inclusion of IKE Header into ICV calculations for each fragment message. > So in the case of no attack, the overhead of your proposed mechanism is > higher. You can't drop an entire message when a single false fragment > arrives, because there could be other valid fragments on the way. So > either way you end up checking the same amount of data, but your > computational overhead is higher. Yes, it is higher, but the amount of the overhead could be estimated about 10%. If some system cannot bear this overhead, I think it is broken. >> But the amount of memory consumption will be smaller if >> you are able to discard false fragments. > > Yes, but you also need to keep some state about pending partial valid > messages. Right. But only after fragment is validated. > AFAICT, the memory difference is more likely to be negligible, but the > processing difference high. No. In solution you have proposed (relying on IP fragmentation inside UDP datagrams) the attacker could send you millions of packets, all with different IP Fragmentation IDs in inner packet. As you has no way to know which Fragmentation ID is valid (from real peer) you will need to try to reassemble all of them, consuming as much memory, as attacker wishes. If attacker is smart enough, s(he) could easy make so, that all the false fragments will eventually be reassembled by your system (into garbage), and you will also consume the CPU power trying to validate them. In this case you will consume roughly the same CPU power as with authenticated fragments, but the amount of your memory consumption will be under attacker's control. >>> attacks (e.g., overloading the receiver with false fragments). >> >> This attack is always possible both with and without fragmentation >> (just overloading with false full messages) and IKE is designed to >> withstand it. >> Handling fragmentation in IKE doesn't make it more vulnerable to this >> attack. >> On the other hand, handling fragmentation outside IKE (on IP level) >> or using unauthenticated fragments in IKE, makes it susceptible to an >> attack, >> described in the rationale, i.e. when attacker spending virtually zero >> resources >> can stop IKE communication by infrequently injecting bad fragments, >> which results in "poisoning" of reassembling queue. Using authenticated >> fragments >> prevents this kind of attack. > > Avoiding fragmentation poisoning attacks is not a motivation of this work. > If you want to make that case, you need to explain why you think that is a > significant issue and worth the effort to fix inside IKE. Actually, Security Consideration Section of RFC5996 has already stated that IP fragmentation is a significant issue for IKE: If the messages of IKEv2 are long enough that IP-level fragmentation is necessary, it is possible that attackers could prevent the exchange from completing by exhausting the reassembly buffers. RFC5996 advices to avoid IP fragmentation by using Hash and URL format for certificates. For some reasons, this is not widely supported by implementations and is not generic solution (some systems transfer a fair amount of data in Configuration Payloads, in which case Hash and URL won't help). The immediate goal of IKE Fragmentation was to deal with devices, that block IP fragments. But the solution is all in line with RFC5996, advicing avoid IP fragmentation whenever possible. > Further, this method does not necessarily avoid IP fragmentation. > Fragments are supposed to pass through a NAT (see my previous reference), > and when they do your mechanism wouldn't adjust the IKE size downward. It doesn't matter. If IP fragmentation works in some environment - it is ok. If it doesn't (either because some intermediate devices block IP fragments or because an attacker is trying to exploit it), then peers detect it and start using IKE Fragmentation. >>> An equally viable solution (see ** below) would involve placing a >>> single signed IKE message into a single IP packet, fragmenting that >>> packet, and transmitting those fragments inside UDP datagrams. This >>> approach could use the innermost IP encapsulation as the reassembly >>> layer. >>> >>> **: Although this approach is susceptible to fragmentation overload, >>> so too is transmitting the original message over IP that is naturally >>> fragmented at the network layer anyway - this introducing no new >>> vulnerability. >> >> But using IKE fragmentation in this case might eliminate this >> vulnerability. > > It might, but again that's not your threat model and there are other > vulnerabilities this method opens up (e.g., replay attacks have a higher > CPU impact). Why? Are you reffering to the fact, that with IKE Fragmentation you need to check 4 additional bytes to detect a replay? Is it really a CPU impact? >>> This IP-encapsulated IKE message would need the same negotiation >>> described in section 2.3, but would avoid the complexity of most of >>> the rest of the document, relying instead on existing IP reassembly. >>> >>> In conclusion, I don't see the need for the level of detail and >>> mechanism proscribed, basically because it reinvents the wheel, but >>> see no other substantial issues with it. >>> >>> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC >>> 4821), and should be described as such. >> >> IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based >> and RFC4821 has many restrictions when used with connectionless >> datagram protocols, some of which are often difficult to satisfy in >> environments, >> where IKE is used. > > You are re-inventing PLMUTD. In places where you claim RFC4821 is too > complex - those are the places where your mechanism is deficient IMO. > E.g., positive verification that a message gets through as a confirmation > of when you've achieved a reasonable size. It is sufficient for IKE. >> Second, the goal of PLMTUD is to find _maximum_ >> MTU size that is not fragmented by IP, in other words, to maximize >> throughput. For IKE the goal of PMTUD is to find _any_reasonable_ >> MTU size that won't be fragmented by IP. Throughput is not important. > > Agreed, but if that's the case, why not always send the smallest possible > message size (68 bytes)? It's because the overhead is too high (additional > headers, blocksize mismatch, and computational startup cost on each > block). Further, most transports don't care about 1400 vs. 1500 bytes; > they're searching for a rough approximation of a 'large' packet, as are > you IMO. I think, the main difference is that PLMTUD is always trying to increase MTU size when everything works fine, while in IKE PMTUD is supposed to decrease it only if packets don't get through. For IKE the former is just not needed. >> Third, PMTU discovery in the draft is completely optional and one may >> use any other mechanisms (including PLMTUD, if it is available) >> to obtain MTU information. > > The transport folks spent a lot of time on PLMTUD; there are a lot of > lessons there that can and should be applied here. PLMTUD is already > flexible enough to apply here directly. You can always reinvent the wheel, > of course. I appreciate the work transport folks has done. I will also appreciate if you point out what exact lessons should be applied here and why. And you may consider PMTUD in IKE as simplified PLMTUD, implemented according with Section 10.4 of RFC4821. > Joe Regards, Valery. From svanru@gmail.com Wed Oct 23 00:14:12 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CAF11E812D; Wed, 23 Oct 2013 00:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyqr4-hSFwlO; Wed, 23 Oct 2013 00:14:11 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5B50611E816D; Wed, 23 Oct 2013 00:14:09 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so304234lab.9 for ; Wed, 23 Oct 2013 00:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=QA+KzCD/rmkpQYo0Z6+OA/gQTFD8iAf6+VKbe6AQ3Fk=; b=UWOxDwUF6G/+3l251qnDZ4vLpQOtdxGejn3ePBsGcNZU+l4v+quqrvRAmpF2gi2sDu LZZYoWI2OYzcABAqXkVbkWkI6ko2JrIpZckbolrvqtwauO6eQ5z7X3UnwZqURjsjOUKg u3XUvoCrOxPJL8YykYX2PAGjQeIvRMvvWy74cX1n3zmR22RCIqbGA73TLVmcJoYu5OcG ycJyoYF4F4VCFktS+VhH6IShiF78DIjFTX89D2F7f6Agi/KnaUJo6OsZwIFERwcKTAi7 G6xejYqU8VLCmIpP2M+gb3g7nnMxtXFcq6VV0uWFqirffUDBAM8WVaWvGXon2oKZIEgp epxw== X-Received: by 10.152.120.73 with SMTP id la9mr81648lab.3.1382512448410; Wed, 23 Oct 2013 00:14:08 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id w10sm18355045lbv.6.2013.10.23.00.14.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Oct 2013 00:14:07 -0700 (PDT) Message-ID: <4CB00D77A6544077B506AF5522843BCD@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> Date: Wed, 23 Oct 2013 11:14:08 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Wed, 23 Oct 2013 03:56:31 -0700 Cc: ipsec@ietf.org, tsv-ads@tools.ietf.org, tsvwg Subject: Re: [tsvwg] [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 07:14:12 -0000 Hi Paul, >>> attacks (e.g., overloading the receiver with false fragments). >> >> This attack is always possible both with and without fragmentation >> (just overloading with false full messages) and IKE is designed to >> withstand it. > > Partially. For unfragmented IKE, the cookies/SPI mitigate this if > you give preference to IKE messages further in the processing queue. > With this draft, I'm forced to do more crypto on IKE packets before I > can decide if these need prioritization or not (with the exception of > the first packet, which cannot get fragmented anyway) The SPIs are still there and you are supposed to check them before you will do any crypto. What is the difference? >> Handling fragmentation in IKE doesn't make it more vulnerable to this >> attack. > > Handling encrypted fragments does, because you will spend more time > doing the crypto. Although this still happens after the cookie/spi > verification. You are doing an additional round of crypto on each fragment > in addition to the regular IKE crypto you need to perform on the assembled > packet. Fragments could be made artificially long and the IKE packet > artificial big, resulting in much more crypto. Now I think this might No, there is no additional round of crypto. After you has verified and decrypted fragment you will store it in decrypted form. After reassembly has finished you will get decrypted message. No more crypto to apply. > not matter much, because the attacker needs to be local and they will > only be local to a remote endpoint which has enough CPU, not the ipsec > core gateway that actually might run out of CPU power when under attack. > >> On the other hand, handling fragmentation outside IKE (on IP level) >> or using unauthenticated fragments in IKE, makes it susceptible to an >> attack, >> described in the rationale, i.e. when attacker spending virtually zero >> resources >> can stop IKE communication by infrequently injecting bad fragments, >> which results in "poisoning" of reassembling queue. > > But the attack is theoretical and of no practical value. I am not so confident. > 1) on-path attacker (remote) > > They can just DOS you regardless by withholding packets. There may be cases when attacker, even on-path, could only eavesdrop and inject packets, but not to block them. > 2) off-path attacker (remote) > > These attackers don't know the cookies/spi's so they can't really sent > a forged fragment you would use for assembly - protected with crypto or > not. It is also impossible for them to time their attack so that one of > their fragments intersect with one of your fragments so they would need > to start sending fragments before the endpoint does but using mostly > wrong cookies/spis and would swamp an endpoint with easilly detectable > forged packets. Again, I am not so confident that it is impossible, especially for particular implementation. Remember, that TCP ISN was also considered impossible to predict untill we saw a successfull attack on particular implementation of TCP. > 3) shared medium like wifi hotspot (local) > > These are the only attackers with enough knowledge to sent sufficiently > advanced bad fragments interfering with incoming fragments. They can > already do all the damage they want without resorting to IKE fragment > spoofing. They can arp spoof the gateway, sent a Wifi de-association > request, sent enough garbage to fill the air waves, and interfere with > the IKE in such a way that you think the remote peer does not support > fragmentation at all. So this draft protects against a local attacker > that wants to masquerade as a network failure and only prevent you from > doing IKE, hoping you will fall back to plaintext traffic. Software > could notify the user that they seem to be under attack, which IMHO > would be more valuable to the user than quiet resilience against the > attack. Sorry, I don't follow your logic here. Security software should thwart the attacks as much, as it could, and not just notify user that he is under attack and give up. DoS attacks are difficult to thwart and sometimes are easy to perform. So what is the reason not to thwart one kind of them? I agree that others are still possible, but they may have their own drawback for attacker and why should we give him/her more options to choose from? >> Using authenticated fragments prevents this kind of attack. > > Yes, it prevents one of the low hanging fruits. Which I don't think is > worth the complexity of this draft compared to the existing > fragmentation code out in the wild. Is it really _much_ complex if you first fragment then encrypt compared to first encrypt then fragment? >> But using IKE fragmentation in this case might eliminate this >> vulnerability. > > At the price of adding more complexity to IKE. With the attacker not > stopped from their goal. See above. >>> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC >>> 4821), and should be described as such. >> >> IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based >> and RFC4821 has many restrictions when used with connectionless >> datagram protocols, some of which are often difficult to satisfy in >> environments, >> where IKE is used. Second, the goal of PLMTUD is to find _maximum_ >> MTU size that is not fragmented by IP, in other words, to maximize >> throughput. For IKE the goal of PMTUD is to find _any_reasonable_ >> MTU size that won't be fragmented by IP. Throughput is not important. >> Third, PMTU discovery in the draft is completely optional and one may >> use any other mechanisms (including PLMTUD, if it is available) >> to obtain MTU information. > > I agree. There is going to be like 2 to 4 fragments. Size does not > matter. It's better to cut down on latency/RTT by using an MTU size > that is for sure to work on the first go. > > But that's also why this complexity is not worth it. Fragmentation does > only mean going from 1 IKE packet to 2-4 IKE packets. The timeframe > to mess with these are in the 5ms range. If an attacker has that > accuracy against you, you've lost already regardless. I doubt the > attacker can even pull it off on wifi. > > The original IKE fragmentation is really nice and simple. Copy part of > the original IKE header, add a single payload with fragment payload > type and fragment number/max, sent fragments in a burst. Not much difference from the draft - just move fragmentation before encryption. > This draft looks like it is fixing a security issue, while it really > should be just about sending smaller packets as similar as possible > to the original single packet. Messing with one IKE packet versus 2-4 > IKE packets is not a real problem that I think needs fixing. It is about sending smaller packets, but doing so in a secure manner. > Paul Regards, Valery. From gorry@erg.abdn.ac.uk Wed Oct 23 05:00:44 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75B011E83C1 for ; Wed, 23 Oct 2013 05:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.462 X-Spam-Level: X-Spam-Status: No, score=-106.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgGzSMJ1u5SG for ; Wed, 23 Oct 2013 05:00:34 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 70BE411E8183 for ; Wed, 23 Oct 2013 05:00:34 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 46A072B43B3; Wed, 23 Oct 2013 13:00:33 +0100 (BST) Received: from ERG-research.local (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id DB4732B44D1 for ; Wed, 23 Oct 2013 13:00:30 +0100 (BST) Message-ID: <5267BA5E.9010302@erg.abdn.ac.uk> Date: Wed, 23 Oct 2013 13:00:30 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: tsvwg WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] Building the TSVWG Agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 12:00:45 -0000 I've uploaded a draft Agenda. This divides the individual draft talks between those on transport protocols and DS/IS: http://www.ietf.org/proceedings/88/agenda/agenda-88-tsvwg If there are any presenters not listed here who would like to be considered please get back asasp, we can then start confirming slots to those marked ???. Best wishes, Gorry From david.black@emc.com Wed Oct 23 07:17:33 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C73811E8390 for ; Wed, 23 Oct 2013 07:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovgzwcx+ywcr for ; Wed, 23 Oct 2013 07:17:28 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF3411E838F for ; Wed, 23 Oct 2013 07:17:28 -0700 (PDT) Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9NEHOPh016220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Oct 2013 10:17:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r9NEHOPh016220 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1382537846; bh=5ONIsym/v8oPmStxVtT1ttvaXHY=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=E9EGsgSK5Jdnd0QoGSL+ktUianJq3mwtdQtPliRu3iReJoTorkEl5dMPy5Bd9n0kD XZqa8EIAeZS6JOMuT2MF25mTpmUvkYB6/SV2N0enD7NRAgOvR6GM+pEUjCHdNdn/Ez vccQKiH5GrKM8wTp4DX2c7yDW9eS3o1DNTA6v6xQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com r9NEHOPh016220 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Wed, 23 Oct 2013 07:17:15 -0700 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9NEHFEL013202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 10:17:15 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Wed, 23 Oct 2013 10:17:15 -0400 From: "Black, David" To: Brian E Carpenter , "tsvwg@ietf.org" Date: Wed, 23 Oct 2013 10:17:14 -0400 Thread-Topic: [tsvwg] I-D Action: draft-geib-tsvwg-diffserv-intercon-04.txt Thread-Index: Ac7PgnNHcJ32g/P0RlO/NP3iuHVYFAAeBTdg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712025DED6E31@MX15A.corp.emc.com> References: <20131018082525.2295.99744.idtracker@ietfa.amsl.com> <526710D1.7050005@gmail.com> In-Reply-To: <526710D1.7050005@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Subject: Re: [tsvwg] I-D Action: draft-geib-tsvwg-diffserv-intercon-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:17:33 -0000 Q2hhbmdpbmcgUHJlY2VkZW5jZSB0byBBZ2dyZWdhdGlvbiBtYWtlcyBzZW5zZSB0byBtZS4NCg0K VGhhbmtzLA0KLS1EYXZpZA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogdHN2d2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZg0KPiBCcmlhbiBFIENhcnBlbnRlcg0KPiBTZW50OiBUdWVzZGF5LCBPY3Rv YmVyIDIyLCAyMDEzIDc6NTcgUE0NCj4gVG86IHRzdndnQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbdHN2d2ddIEktRCBBY3Rpb246IGRyYWZ0LWdlaWItdHN2d2ctZGlmZnNlcnYtaW50ZXJjb24t MDQudHh0DQo+IA0KPiBIaSBSw7xkaWdlciwNCj4gDQo+ID4gICAgRFNDUCBQcmVjZWRlbmNlIFBy ZWZpeCAgVGhlIGJpdHMgMC0yIG9mIHRoZSBEU0NQIChtYXJrZWQgIngiIGluIHRoaXMNCj4gPiAg ICAgICAgICAgIGdlbmVyaWMgRFNDUCBmaWVsZDogeHh4ZGRkKSBhcmUgY2FsbGVkIHRoZSBEU0NQ IFByZWNlZGVuY2UNCj4gPiAgICAgICAgICAgIFByZWZpeCBbUkZDMjQ3NF0gaW4gdGhlIGZvbGxv d2luZy4gIEJ5IGlnbm9yaW5nIHRoZSB2YWx1ZSBvZg0KPiA+ICAgICAgICAgICAgYml0cyAzLTYg KCBkIHN0YW5kcyBmb3IgZG9uJyBjYXJlKSwgYSBzaW1wbGUgYWdncmVnYXRpb24gb2YNCj4gPiAg ICAgICAgICAgIFBIQnMgZGlmZmVyZWQgYnkgRFNDUCBpcyBwb3NzaWJsZSBpbiBJUCBhbmQgTVBM UyBiYWNrYm9uZXMsDQo+ID4gICAgICAgICAgICBidXQgYWxzbyBpZiBFdGhlcm5ldCB0cmFuc3Bv cnQgaXMgYXBwbGllZC4NCj4gDQo+IFRoYW5reW91IGZvciBwcm92aWRpbmcgZXhwbGljaXQgdGVy bWlub2xvZ3kgZm9yIHRoaXMuIEkgYW0gc3RpbGwgd29ycmllZA0KPiB0aGF0IGJ5IHJldml2aW5n IHRoZSB3b3JkICJwcmVjZWRlbmNlIiB3ZSB3b3VsZCBzZXJpb3VzbHkgZGFtYWdlIG91dHNpZGVy cycNCj4gdW5kZXJzdGFuZGluZyBvZiBkaWZmZXJlbnRpYXRlZCBzZXJ2aWNlcy4gVGhlIHNwZWNp ZmljIHJlYXNvbiB3ZSBnb3QgcmlkDQo+IG9mICJwcmVjZWRlbmNlIiBhbmQgdGhlIG5vdGlvbiBv ZiBzaW1wbGUgcHJpb3JpdHkgKGV4Y2VwdCBmb3IgaW1wbGVtZW50aW5nDQo+IHRoZSBsZWdhY3kg Y29kZSBwb2ludHMpIHdhcyB0byB1bmRlcmxpbmUgdGhhdCBwcmVjZWRlbmNlIGRvZXNuJ3QgcHJv dmlkZQ0KPiBxdWFsaXR5IG9mIHNlcnZpY2U7IGlmIGFueXRoaW5nLCBpdCBwcm92aWRlcyBxdWFs aXR5IG9mIGRpc3NlcnZpY2UuDQo+IA0KPiBDb3VsZG4ndCB5b3UgY2FsbCB0aG9zZSB0aHJlZSBi aXRzICJEU0NQIEFnZ3JlZ2F0aW9uIFByZWZpeCI/IFRoZW4gdGhleQ0KPiB3b3VsZCByZWZlciB0 byA4IHRyYWZmaWMgY2xhc3NlcywgYW5kIG9ubHkgaW4gYSB2ZXJ5IHByaW1pdGl2ZQ0KPiBpbXBs ZW1lbnRhdGlvbiB3b3VsZCB0aGV5IGJlIG1hcHBlZCB0byBwcmlvcml0eSBsZXZlbHMuDQo+IA0K PiAgICAgQnJpYW4NCj4gDQoNCg== From touch@isi.edu Wed Oct 23 10:23:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C84A11E81E4; Wed, 23 Oct 2013 10:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.054 X-Spam-Level: X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY+Wdry19jgu; Wed, 23 Oct 2013 10:23:36 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A178611E81B3; Wed, 23 Oct 2013 10:23:36 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9NHMbCx023189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Oct 2013 10:22:44 -0700 (PDT) Message-ID: <5268060B.4060604@isi.edu> Date: Wed, 23 Oct 2013 10:23:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 17:23:42 -0000 On 10/22/2013 11:25 PM, Valery Smyslov wrote: > I appreciate the work transport folks has done. I will also appreciate > if you point out what exact lessons should be applied here and why. > And you may consider PMTUD in IKE as simplified PLMTUD, > implemented according with Section 10.4 of RFC4821. From the second sentence of that section: Because you never generate distinct probes, finding out when the MTU fails is tied to timeouts in your message exchange system, rather than being decoupled. From Section 9: You don't talk about trying to make sure that IPv4 DF is set, as per Section 9, which means that even the conservative values you pick might continue to generate fragments downstream. Finally, and this is separate from RFC4821, you don't mention the fact that dropping fragments is against the recommended behavior for NATs. I appreciate trying to get around that issue, but it's equally important to indicate this as a flaw of the network, rather than "just the way it is". Joe From jiangsheng@huawei.com Wed Oct 23 18:12:41 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5780611E80E8 for ; Wed, 23 Oct 2013 18:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gESak72CWn1W for ; Wed, 23 Oct 2013 18:12:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0A27911E82AB for ; Wed, 23 Oct 2013 18:12:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXD13519; Thu, 24 Oct 2013 01:12:22 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 02:12:17 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 02:12:05 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.191]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0146.000; Thu, 24 Oct 2013 09:11:57 +0800 From: Sheng Jiang To: "gorry@erg.abdn.ac.uk" , tsvwg WG Thread-Topic: [tsvwg] Building the TSVWG Agenda Thread-Index: AQHOz+eGc2Y0GbJ0UEmcv+cDwzs9e5oDBrjQ Date: Thu, 24 Oct 2013 01:11:56 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AD4D0C7@nkgeml512-mbx.china.huawei.com> References: <5267BA5E.9010302@erg.abdn.ac.uk> In-Reply-To: <5267BA5E.9010302@erg.abdn.ac.uk> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [tsvwg] Building the TSVWG Agenda X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 01:12:41 -0000 V2Ugd291bGQgbGlrZSB0byBwcmVzZW50IGRyYWZ0LXlpbi10c3Z3Zy1pcGZsb3ctcGF0aHRyYWNl LXBzLTAxLCAxMC1taW51dGUgc2xvdCBzaG91bGQgYmUgZW5vdWdoLiBTaGVuZyB3aWxsIGJlIHRo ZSBwcmVzZW50ZXIuDQoNCk1hbnkgdGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMsDQoNClNoZW5nICsg WXVhbmJpbg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiB0c3Z3Zy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ T2YgR29ycnkgRmFpcmh1cnN0DQo+U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIzLCAyMDEzIDg6 MDEgUE0NCj5UbzogdHN2d2cgV0cNCj5TdWJqZWN0OiBbdHN2d2ddIEJ1aWxkaW5nIHRoZSBUU1ZX RyBBZ2VuZGENCj4NCj4NCj5JJ3ZlIHVwbG9hZGVkIGEgZHJhZnQgQWdlbmRhLiBUaGlzIGRpdmlk ZXMgdGhlIGluZGl2aWR1YWwgZHJhZnQgdGFsa3MNCj5iZXR3ZWVuIHRob3NlIG9uIHRyYW5zcG9y dCBwcm90b2NvbHMgYW5kIERTL0lTOg0KPg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvODgvYWdlbmRhL2FnZW5kYS04OC10c3Z3Zw0KPg0KPklmIHRoZXJlIGFyZSBhbnkgcHJlc2Vu dGVycyBub3QgbGlzdGVkIGhlcmUgd2hvIHdvdWxkIGxpa2UgdG8gYmUNCj5jb25zaWRlcmVkIHBs ZWFzZSBnZXQgYmFjayBhc2FzcCwgd2UgY2FuIHRoZW4gc3RhcnQgY29uZmlybWluZyBzbG90cyB0 bw0KPnRob3NlIG1hcmtlZCA/Pz8uDQo+DQo+QmVzdCB3aXNoZXMsDQo+DQo+R29ycnkNCg== From svanru@gmail.com Wed Oct 23 23:42:56 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A5111E8109; Wed, 23 Oct 2013 23:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abRt2a7XgaYB; Wed, 23 Oct 2013 23:42:55 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A825221E8090; Wed, 23 Oct 2013 23:42:48 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id el20so1521496lab.16 for ; Wed, 23 Oct 2013 23:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=h5v/JY+TyOY81HtEiKM3CifNhY3ZV/tMYUX+rCiW8dI=; b=JVBi3VJj4xmy5qTzVetSWxscgwY60/ugwK3Wi1w/VfCr2T9KWdwSZk6UwX2ghSiXFI pG3xF1qj0RIgpM7UucZcBwL3UzU4YLaWnuGFuwJbT8gtssNL7B/iNFHL63v83hAiFo7L 6ZKZjBU7vkjzheDXw4f6aL7n+XRqkkBWbfHVCfYYHfeKVNaNzEXcxFdEEzwpaOuFMTvZ 44R3wDCaLdGsOdumxOhnCpuORH0HzqK8WiGBdESh7vgCYYHXeYR8yoV4rfjORSH+igph Au95VGYBRRhonUn0rjeygFCmjy5G3Vf/eEcXnutgL7ZuYkgy7i1tAA0mWDd3CpTOkALL hwTw== X-Received: by 10.152.29.38 with SMTP id g6mr785962lah.25.1382596967419; Wed, 23 Oct 2013 23:42:47 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ao4sm124957lac.1.2013.10.23.23.42.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Oct 2013 23:42:46 -0700 (PDT) Message-ID: <81953CE6126542A8AD40207921B8E018@buildpc> From: "Valery Smyslov" To: "Joe Touch" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> Date: Thu, 24 Oct 2013 10:42:50 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Thu, 24 Oct 2013 00:45:44 -0700 Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 06:42:56 -0000 Hi Joe, thank you for your suggestions. I still have some comments. > On 10/22/2013 11:25 PM, Valery Smyslov wrote: >> I appreciate the work transport folks has done. I will also appreciate >> if you point out what exact lessons should be applied here and why. >> And you may consider PMTUD in IKE as simplified PLMTUD, >> implemented according with Section 10.4 of RFC4821. > > From the second sentence of that section: Because you never generate > distinct probes, finding out when the MTU fails is tied to timeouts in > your message exchange system, rather than being decoupled. That's true. I don't see any requirements in section 10.4. that the probes must be distinct. Request/reply nature of IKE's messages make them well suitable for probes and I see no need here to introduce separate mechanism, adding complexity, consuming bandwith and adding delay. Moreover, section 10.4 explicitely allows using application data for probes. > From Section 9: You don't talk about trying to make sure that IPv4 DF is > set, as per Section 9, which means that even the conservative values you > pick might continue to generate fragments downstream. With all due respect, I have to disagree that setting DF bit is needed in case of IKE. With IKE the goal is not to make sure that _no_ IP fragmentation takes place on the path, but to make sure that IP fragmentation issues, if any, do not prevent IKE communications. So, IP fragmentation is present on the path, but it doesn't bother us - let it be. If it doesn't allow IKE to work (either by dropping IP fragments or by attacking destination host with bogus fragments) - we will try to avoid it. So, in your example, even if IP fragments are generated downstream, but those fragments are passed - let them be. Note, that this approach is in line with advices, given for IKE in the paper C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003. that is reffered by RFC5996 as recommendations to protect against IP fragmentation issues. Section 3.3 of this paper discusses the ways PMTUD should be done in IKE and finds it more advantageous not to set DF bit. > Finally, and this is separate from RFC4821, you don't mention the fact > that dropping fragments is against the recommended behavior for NATs. I > appreciate trying to get around that issue, but it's equally important to > indicate this as a flaw of the network, rather than "just the way it is". That's true and I will definitely add some words about it. > Joe Thank you, Valery Smyslov. From touch@isi.edu Thu Oct 24 10:05:38 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06B811E8246; Thu, 24 Oct 2013 10:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrCX1MTTo34v; Thu, 24 Oct 2013 10:05:28 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8C11E8189; Thu, 24 Oct 2013 10:05:07 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9OH4oFR002866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Oct 2013 10:04:50 -0700 (PDT) Message-ID: <52695365.4070803@isi.edu> Date: Thu, 24 Oct 2013 10:05:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> In-Reply-To: <81953CE6126542A8AD40207921B8E018@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 17:05:44 -0000 On 10/23/2013 11:42 PM, Valery Smyslov wrote: > Hi Joe, > > thank you for your suggestions. I still have some comments. > >> On 10/22/2013 11:25 PM, Valery Smyslov wrote: >>> I appreciate the work transport folks has done. I will also appreciate >>> if you point out what exact lessons should be applied here and why. >>> And you may consider PMTUD in IKE as simplified PLMTUD, >>> implemented according with Section 10.4 of RFC4821. >> >> From the second sentence of that section: Because you never generate >> distinct probes, finding out when the MTU fails is tied to timeouts in >> your message exchange system, rather than being decoupled. > > That's true. I don't see any requirements in section 10.4. that the probes > must be distinct. Request/reply nature of IKE's messages make them > well suitable for probes and I see no need here to introduce > separate mechanism, adding complexity, consuming bandwith and adding delay. > Moreover, section 10.4 explicitely allows using application data for > probes. Yes, but there are two components: - the probes - the timeouts You're using existing IKE messages *and* existing timeouts to determine when there is a problem. A separate timer would be useful, if only to allow you to decouple fragment retransmission from IKE transaction retries. >> From Section 9: You don't talk about trying to make sure that IPv4 DF >> is set, as per Section 9, which means that even the conservative >> values you pick might continue to generate fragments downstream. > > With all due respect, I have to disagree that setting DF bit is needed > in case of IKE. > With IKE the goal is not to make sure that _no_ IP fragmentation takes > place > on the path, but to make sure that IP fragmentation issues, if any, > do not prevent IKE communications. So, IP fragmentation is present on > the path, > but it doesn't bother us - let it be. Agreed. But that's the case when IKE works with whatever message size you start with. > If it doesn't allow IKE to work > (either by dropping IP fragments or by attacking destination host with > bogus fragments) - we will try to avoid it. So, in your example, even if > IP fragments are generated downstream, but those fragments are passed - > let them be. Your mechanism kicks in (presumably) when IKE fails, and then you retry with application-layer fragments. App-layer fragments are useless if the network level then fragments the messages. That's why you should set DF=1. > Note, that this approach is in line with advices, given for IKE in the > paper > > C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection > for UDP-based protocols", ACM Conference on Computer and > Communications Security, October 2003. That paper doesn't consider IKE-level fragmentation, which you're introducing. I agree that DF=0 for IKE without IKE-level fragmentation. > that is reffered by RFC5996 as recommendations to protect against IP > fragmentation issues. Section 3.3 of this paper discusses the ways PMTUD > should be done in IKE and finds it more advantageous not to set DF bit. That too refers to IKE without IKE-level fragmentation (see Sec 2). Again, once you introduce fragmentation at the IKE-level to avoid IP fragmentation, it makes no sense to continue to allow it at the IP level. Joe From touch@isi.edu Fri Oct 25 13:18:51 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A6011E814F; Fri, 25 Oct 2013 13:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNQMFLIwQH9i; Fri, 25 Oct 2013 13:18:45 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7FE11E8145; Fri, 25 Oct 2013 13:18:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9PKI1RM016453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Oct 2013 13:18:01 -0700 (PDT) Message-ID: <526AD233.3090109@isi.edu> Date: Fri, 25 Oct 2013 13:18:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:18:51 -0000 On 10/24/2013 10:45 PM, Valery Smyslov wrote: ... >> You're using existing IKE messages *and* existing timeouts to >> determine when there is a problem. A separate timer would be useful, >> if only to allow you to decouple fragment retransmission from IKE >> transaction retries. > > No, the timeouts are different. I should have made it more expplicit in > the draft. That'd be useful. ... > Always setting DF bit in this case will probably increase the delay > before IKE SA is set up (as more probes will need to be done). Except that if you continue to allow IP fragmentation, you can't claim your solution is robust to IP fragment poisoning. >>> Note, that this approach is in line with advices, given for IKE in the >>> paper >>> >>> C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection >>> for UDP-based protocols", ACM Conference on Computer and >>> Communications Security, October 2003. >> >> That paper doesn't consider IKE-level fragmentation, which you're >> introducing. I agree that DF=0 for IKE without IKE-level fragmentation. > > It does, in Section 3.3. Sorry - I missed that. But that section also gives good reasons why this is a bad idea in IKE too. Joe From mattmathis@google.com Fri Oct 25 13:41:08 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163E211E8145 for ; Fri, 25 Oct 2013 13:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+ummHUX7Gbk for ; Fri, 25 Oct 2013 13:41:07 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A56C011E8152 for ; Fri, 25 Oct 2013 13:41:06 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id aq17so7522117iec.10 for ; Fri, 25 Oct 2013 13:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UQTVFtRNXd9LQbN5lbw7sNy8vGgA4GqkNfJUSR/ZJ+g=; b=Xnw2CTlxmWL9z7tJLINkk/w+F+orLF0qqd3MDVo26ijBUVU0L7Ht7pbJXdpxlcYgSW nZ/CKSTmLy2bmTdLdzlanLjQV1sqLRQzC3ymdMQ46s4vWgP6mpq1j7vR307UVnGanw0e u4yQKiZpdnsc7e8xJ1o1TWE29Ga1pDQtahplT0exlouZzogiIiigp6LcMcr3AWGSI1Ky ayg7n5Vx47jugHJNIiNY1Uq0UaR/p40VH2ou5BpajPeplGwZkU2Rs79Parp1Xrxt+N9q G0f9xoQ0bsDmgxECBbEg054md++C4BWxWvhMo4LEAzfUzTiy9KPLayJO1vjPqf1Un1eZ NxUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UQTVFtRNXd9LQbN5lbw7sNy8vGgA4GqkNfJUSR/ZJ+g=; b=Jpj/hYrr+alk6marqWGL15du9nP9Y3ADSE+W8QwiyA+OSOFZpHfP9lPtj7gJAO4c0U N8nQSV4HYnTDMmehwL/Vs5EUfKPwb3GOoEI5Vnqzpdv/eHt4p6O6bg4SXMbe05BRD3Nl aAqwjSPT4n0Ai3sf2Rl0Wq8bITZ7y4vno6FpRtfocPOSI+oeoRYlISwuHWI27f1ZPy3f STnDEs+CVzeGh5tqGVtQ3I9nSr8ROlyLOcS6Amsqm10IbN4sVIum7Cx1PsVKlqKaAonf aJ16kzC9EghdCl1jKAOKRPIt2pJX5WYOyzyUgkgwYXsBZAMTfdSJwpi8ad1kNqTLP7RA 4ZvA== X-Gm-Message-State: ALoCoQlcGNHufFo9fZlx4N2f53RAHgCQMA5qMP9UY5VKJpKMjX5W82xh2HEX7WVv1uilqCDTMiMt64+tK5C+1Hms2mT03YlIMfQQlHpE4nJ5kqaSA/hLTUGeOryDqBE0Wnk9zTqc6lb2J2Rc/bQ5p43WaF46EYxX5zDfAiIkHpBlMHSJBxEOT07CarkBSNujNkCKR8LQlnEq MIME-Version: 1.0 X-Received: by 10.50.23.16 with SMTP id i16mr110704igf.50.1382733666033; Fri, 25 Oct 2013 13:41:06 -0700 (PDT) Received: by 10.64.243.66 with HTTP; Fri, 25 Oct 2013 13:41:05 -0700 (PDT) In-Reply-To: <526AD233.3090109@isi.edu> References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> Date: Fri, 25 Oct 2013 13:41:05 -0700 Message-ID: From: Matt Mathis To: Valery Smyslov Content-Type: multipart/alternative; boundary=089e0158a9aafbfe5404e996c45d Cc: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, "tsv-dir@ietf.org" Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:41:08 -0000 --089e0158a9aafbfe5404e996c45d Content-Type: text/plain; charset=ISO-8859-1 I concur with Joe: once you have enough machinery work well with IPv6 fragmentation semantics, you should use it for IPv4 too, and unconditionally set DF. This probably applies to *all* protocols. IPv4 reassembly is hopelessly out of scale. IP ID wrap times are likely to be sub second for any large CGN connecting to any large service..... They might even be shorter than the queuing times. I suspect that if you re-review decade old papers on fragmentation, you will find some scale assumptions that are no longer correct. In that time the Internet has moved at least another two orders of magnitude in packet rates. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch wrote: > > > On 10/24/2013 10:45 PM, Valery Smyslov wrote: > ... > >> You're using existing IKE messages *and* existing timeouts to >>> determine when there is a problem. A separate timer would be useful, >>> if only to allow you to decouple fragment retransmission from IKE >>> transaction retries. >>> >> >> No, the timeouts are different. I should have made it more expplicit in >> the draft. >> > > That'd be useful. > > ... > >> Always setting DF bit in this case will probably increase the delay >> before IKE SA is set up (as more probes will need to be done). >> > > Except that if you continue to allow IP fragmentation, you can't claim > your solution is robust to IP fragment poisoning. > > Note, that this approach is in line with advices, given for IKE in the >>>> paper >>>> >>>> C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection >>>> for UDP-based protocols", ACM Conference on Computer and >>>> Communications Security, October 2003. >>>> >>> >>> That paper doesn't consider IKE-level fragmentation, which you're >>> introducing. I agree that DF=0 for IKE without IKE-level fragmentation. >>> >> >> It does, in Section 3.3. >> > > Sorry - I missed that. But that section also gives good reasons why this > is a bad idea in IKE too. > > Joe > --089e0158a9aafbfe5404e996c45d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I concur with Joe: once you have enough machinery work wel= l with IPv6 fragmentation semantics, you should use it for IPv4 too, and un= conditionally set DF. =A0 This probably applies to *all* protocols.
IPv4 reassembly is hopelessly out of scale. =A0IP ID wrap times = are likely to be sub second for any large CGN connecting to any large servi= ce..... =A0They might even be shorter than the queuing times.

I suspect that if you re-review decade old papers on fragmentation, yo= u will find some scale assumptions that are no longer correct. =A0In that t= ime the Internet has moved at least another two orders of magnitude in pack= et rates.

Thanks,
--MM--
The best way to predict the future is to cr= eate it. =A0- Alan Kay

Privacy matters! =A0We know from recent event= s that people are using our services to speak in defiance of unjust governm= ents. =A0 We treat privacy and security as matters of life and death, becau= se for some users, they are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe Tou= ch <touch@isi.edu> wrote:


On 10/24/2013 10:45 PM, Valery Smyslov wrote:
...
You're using existing IKE messages *and* existing timeouts to
determine when there is a problem. A separate timer would be useful,
if only to allow you to decouple fragment retransmission from IKE
transaction retries.

No, the timeouts are different. I should have made it more expplicit in
the draft.

That'd be useful.

...
Always setting DF bit in this case will probably increase the delay
before IKE SA is set up (as more probes will need to be done).

Except that if you continue to allow IP fragmentation, you can't claim = your solution is robust to IP fragment poisoning.

Note, that this approach is in line with advices, given for IKE in the
paper

C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection
=A0 =A0 =A0 =A0 =A0 =A0 =A0 for UDP-based protocols", ACM Conference o= n Computer and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Communications Security, October 2003.

That paper doesn't consider IKE-level fragmentation, which you're introducing. I agree that DF=3D0 for IKE without IKE-level fragmentation.

It does, in Section 3.3.

Sorry - I missed that. But that section also gives good reasons why this is= a bad idea in IKE too.

Joe

--089e0158a9aafbfe5404e996c45d-- From bob.briscoe@bt.com Fri Oct 25 14:16:30 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8947811E81EC; Fri, 25 Oct 2013 14:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQh62ZfZC6IT; Fri, 25 Oct 2013 14:16:25 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC7511E8213; Fri, 25 Oct 2013 14:16:22 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 25 Oct 2013 22:16:17 +0100 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 25 Oct 2013 22:16:18 +0100 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Fri, 25 Oct 2013 22:16:12 +0100 Received: from BTP075694.jungle.bt.co.uk ([10.111.172.244]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9PLGAFp007348; Fri, 25 Oct 2013 22:16:10 +0100 Message-ID: <201310252116.r9PLGAFp007348@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Oct 2013 22:16:09 +0100 To: Matthew Ford From: Bob Briscoe In-Reply-To: <657D1484-1B02-41F5-9FD1-0921439DF754@isoc.org> References: <201309171233.r8HCXKkV003952@bagheera.jungle.bt.co.uk> <201310212340.r9LNee5p025162@bagheera.jungle.bt.co.uk> <657D1484-1B02-41F5-9FD1-0921439DF754@isoc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_552357903==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "aqm@ietf.org" , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Immediate and Explicit Congestion Notification (was: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:16:30 -0000 --=====================_552357903==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Mat, At 11:56 22/10/2013, Matthew Ford wrote: >On 22 Oct 2013, at 00:40, Bob Briscoe wrote: > > > There's more to it - I've asked to present the whole story in Vancouver. > >Cool, looking forward to it. I'll prime the question pump now if I may: > >Does the transport need to know that it is connected to a network >that will signal ECN in this fashion? Here's the outline of the talk I'm planning, that I sent to Martin originally. Most of the second half addresses your question. Exec summary * Early tests show promise that we may have found a way to make the ultra-low queuing delay of data centre TCP incrementally deployable on the public Internet * For rtcweb, we need to address a) cc for r-t media [rmcat w-g in progress] b) Making TCP nicer c) minimise ability of TCP to bloat queues [AQM w-g now in progress] This addresses b) & c) The problem * All AQMs delay dropping for about one (hard-coded) worst-case RTT, in case a burst dissipates (allegedly a 'good queue' according to Van Jacobson) * For a flow with 1/10 or 1/100 of this RTT (e.g. from a CDN or your home media server), any congestion signal is delayed tens or hundreds of its own RTTs by these AQMs. * A TCP flow in slow-start doesn't need the burst smoothed anyway - delaying the signal just makes slow-start overshoot more - a TCP in slow-start knows that it won't allow the burst to dissipate anyway The solution: make ECN also mean "Immediate Congestion Notification"? * For ECN-capable packets, shift the job of hiding bursts from network to host: - the network signals ECN with no smoothing delay - then the transport can hide bursts of ECN signals from itself - the transport knows o whether it's TCP or RTP etc, o whether its in congestion avoidance or slow-start, o and it knows its RTT, o so it can know whether to respond immediately or to smooth the signals, o and if so, over what time - then short RTT flows can smooth the signals with only the delay of their /own/ RTT o so they can fill troughs and absorb peaks that longer RTT flows cannot - a TCP only needs to smooth the signals if in congestion avoidance o in slow start, it can respond immediately, thus reducing overshoot Incremental Deployment: * Immediate congestion notification doesn't need new AQM implementation - it can use the widely implemented WRED algorithm with an unexpected configuration * The network classifies packets for this AQM treatment based on their ECN-capability - Without ECN, it smoothes the queue before signalling drops - With ECN, it signals immediately, without any smoothing delay - (as today, the operator can still use WRED with the Diffserv field too) * For TCP apps, the stack will use 'DCTCP' (we've tweaked it), if the ends negotiate ECN with the accurate feedback capability. * It should 'just work' if an RTP app or a Reno TCP uses ECN. The request: * Much more evaluation to do, but first we want to know: - if the idea works, would the IETF have an appetite for tweaking the definition of ECN so it is merely equivalent to drop in the long term, but the dynamics need not be equivalent. Much better than the ECN that didn't get deployed * This is Explicit and Immediate Congestion Notification (EICN?) - same wire protocol, much greater benefits * The advantage of the original ECN (avoiding congestive loss) was too small to be worth the deployment hassle * Predictable ultra-low latency without loss too (similar to DCTCP-ECN) would be worth deploying * But we all thought DCTCP could only be deployed in isolation (e.g. data centres) - we all thought DCTCP traffic would starve alongside today's TCP traffic - because in a DCTCP queue, the ECN threshold is lower than you would trigger drop - and we thought ECN & drop had to be equivalent. * We believe we've found a way to ensure DCTCP-ECN traffic doesn't starve - we still make DCTCP-ECN equivalent to drop in the long-run, but not in its dynamics More info A paper with early results is under submission (available on request). It shows neither this approach nor legacy traffic can starve the other under a wide range of conditions, but we have a lot more work to test the limits. Bob >Mat > >_______________________________________________ >aqm mailing list >aqm@ietf.org >https://www.ietf.org/mailman/listinfo/aqm ________________________________________________________________ Bob Briscoe, BT --=====================_552357903==.ALT Content-Type: text/html; charset="us-ascii" Mat,

At 11:56 22/10/2013, Matthew Ford wrote:

On 22 Oct 2013, at 00:40, Bob Briscoe <bob.briscoe@bt.com> wrote:

> There's more to it - I've asked to present the whole story in Vancouver.

Cool, looking forward to it. I'll prime the question pump now if I may:

Does the transport need to know that it is connected to a network that will signal ECN in this fashion?

Here's the outline of the talk I'm planning, that I sent to Martin originally. Most of the second half addresses your question.

Exec summary
* Early tests show promise that we may have found a way to make the ultra-low queuing delay of data centre TCP incrementally deployable on the public Internet
* For rtcweb, we need to address
  a) cc for r-t media [rmcat w-g in progress]
  b) Making TCP nicer
  c) minimise ability of TCP to bloat queues [AQM w-g now in progress]
  This addresses b) & c)

The problem
* All AQMs delay dropping for about one (hard-coded) worst-case RTT, in case a burst dissipates (allegedly a 'good queue' according to Van Jacobson)
* For a flow with 1/10 or 1/100 of this RTT (e.g. from a CDN or your home media server), any congestion signal is delayed tens or hundreds of its own RTTs by these AQMs.
* A TCP flow in slow-start doesn't need the burst smoothed anyway
  - delaying the signal just makes slow-start overshoot more
  - a TCP in slow-start knows that it won't allow the burst to dissipate anyway

The solution: make ECN also mean "Immediate Congestion Notification"?
* For ECN-capable packets, shift the job of hiding bursts from network to host:
  - the network signals ECN with no smoothing delay
  - then the transport can hide bursts of ECN signals from itself
  - the transport knows
    o whether it's TCP or RTP etc,
    o whether its in congestion avoidance or slow-start,
    o and it knows its RTT,
    o so it can know whether to respond immediately or to smooth the signals,
    o and if so, over what time
  - then short RTT flows can smooth the signals with only the delay of their /own/ RTT
    o so they can fill troughs and absorb peaks that longer RTT flows cannot
  - a TCP only needs to smooth the signals if in congestion avoidance
    o in slow start, it can respond immediately, thus reducing overshoot

Incremental Deployment:
* Immediate congestion notification doesn't need new AQM implementation
  - it can use the widely implemented WRED algorithm with an unexpected configuration
* The network classifies packets for this AQM treatment based on their ECN-capability
  - Without ECN, it smoothes the queue before signalling drops
  - With ECN, it signals immediately, without any smoothing delay
  - (as today, the operator can still use WRED with the Diffserv field too)
* For TCP apps, the stack will use 'DCTCP' (we've tweaked it), if the ends negotiate ECN with the accurate feedback capability.
* It should 'just work' if an RTP app or a Reno TCP uses ECN.

The request:
* Much more evaluation to do, but first we want to know:
  - if the idea works, would the IETF have an appetite for tweaking the definition of ECN so it is merely equivalent to drop in the long term, but the dynamics need not be equivalent.


Much better than the ECN that didn't get deployed
* This is Explicit and Immediate Congestion Notification (EICN?)
  - same wire protocol, much greater benefits
* The advantage of the original ECN (avoiding congestive loss) was too small to be worth the deployment hassle
* Predictable ultra-low latency without loss too (similar to DCTCP-ECN) would be worth deploying
* But we all thought DCTCP could only be deployed in isolation (e.g. data centres)
  - we all thought DCTCP traffic would starve alongside today's TCP traffic
  - because in a DCTCP queue, the ECN threshold is lower than you would trigger drop
  - and we thought ECN & drop had to be equivalent.
* We believe we've found a way to ensure DCTCP-ECN traffic doesn't starve
  - we still make DCTCP-ECN equivalent to drop in the long-run, but not in its dynamics

More info
A paper with early results is under submission  (available on request). It shows neither this approach nor legacy traffic can starve the other under a wide range of conditions, but we have a lot more work to test the limits.



Bob


Mat

_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT --=====================_552357903==.ALT-- From david.black@emc.com Fri Oct 25 18:04:20 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A3611E818F for ; Fri, 25 Oct 2013 18:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fT8el6OeziJ for ; Fri, 25 Oct 2013 18:04:16 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8127311E81D0 for ; Fri, 25 Oct 2013 18:04:14 -0700 (PDT) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9Q14DTD029403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Oct 2013 21:04:13 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com r9Q14DTD029403 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1382749453; bh=6Wm/PJ9VM6br3ou5SkwcpUD/2sE=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=vJEHJPWz/4tfx1keRUTuMYoQTDPYXn7BEuJJFQ3ZeMbd4h9oXXcyMwwpwZ6Bzt7/9 kfNta8ssBF3M6jAocbQsKOpm5O2qLzh0hDBKc4yhKNmJW/Hy8pAp+fDOLDIFCYTs7B BFaG8XJys+610MfJ1Kau5I3iYv9bUQWICop+PcOs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com r9Q14DTD029403 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd01.lss.emc.com (RSA Interceptor) for ; Fri, 25 Oct 2013 21:03:54 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r9Q13rj8018348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Oct 2013 21:03:54 -0400 Received: from mx15a.corp.emc.com ([169.254.1.46]) by mxhub33.corp.emc.com ([::1]) with mapi; Fri, 25 Oct 2013 21:03:53 -0400 From: "Black, David" To: "tsvwg@ietf.org" Date: Fri, 25 Oct 2013 21:03:51 -0400 Thread-Topic: Asking for tsvwg meeting time Thread-Index: Ac7R5zws0FuhZyqQS5mozuV3vRBcGw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712025DED7409@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Subject: [tsvwg] Asking for tsvwg meeting time X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 01:04:20 -0000 I thought I'd pass along some wise advice from Melinda Shore, one of the chairs of the opsawg WG - it also applies to tsvwg WG agenda time: It seems to have become a matter of standard practice for someone to request time on the agenda to discuss a draft that we've never seen before and which has received no discussion. We always write back and tell them there really needs to be discussion on the mailing list so that we can gauge interest, relevance, and quality, and so the author sends email to tsvwg at ietf.org. You can save yourself a round trip and possibly a bit of time by starting a mailing list discussion first. http://www.ietf.org/mail-archive/web/opsawg/current/msg02987.html FYI, --David (for the tsvwg WG co-chairs) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From john@jlc.net Sat Oct 26 05:16:43 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D27811E824B; Sat, 26 Oct 2013 05:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.304 X-Spam-Level: X-Spam-Status: No, score=-106.304 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5UaVVpGG6Vl; Sat, 26 Oct 2013 05:16:38 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0B11E8199; Sat, 26 Oct 2013 05:16:34 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id D78C2C94C2; Sat, 26 Oct 2013 08:16:32 -0400 (EDT) Date: Sat, 26 Oct 2013 08:16:32 -0400 From: John Leslie To: Bob Briscoe Message-ID: <20131026121632.GJ65952@verdi> References: <201309171233.r8HCXKkV003952@bagheera.jungle.bt.co.uk> <201310212340.r9LNee5p025162@bagheera.jungle.bt.co.uk> <657D1484-1B02-41F5-9FD1-0921439DF754@isoc.org> <201310252116.r9PLGAFp007348@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201310252116.r9PLGAFp007348@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: "aqm@ietf.org" , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Immediate and Explicit Congestion Notification (was: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 12:16:43 -0000 (If this continues, we've got to fix the title and cross-posting...) Bob Briscoe wrote: > > Exec summary > * Early tests show promise that we may have found a way to make the > ultra-low queuing delay of data centre TCP incrementally deployable > on the public Internet > * For rtcweb, we need to address > a) cc for r-t media [rmcat w-g in progress] > b) Making TCP nicer > c) minimise ability of TCP to bloat queues [AQM w-g now in progress] > This addresses b) & c) > > The problem > * All AQMs delay dropping for about one (hard-coded) worst-case RTT, > in case a burst dissipates (allegedly a 'good queue' according to Van > Jacobson) This assertion is going to need a lot of support. Bob is a man after my own heart suggesting that an ECN notification may be sent earlier than a packet drop would be indicated. I don't know if we can get there; but IMHO that is essential to getting ECN deployed and used. I don't think I agree with Bob that what's hard-coded is necessarily a "worst-case" RTT -- and I'm quite sure I'm not willing to make any pronouncement about "all AQMs". I suggest the talk might be more useful if Bob outlined the AQMs currently in widespread use and detailed _how_ they delay dropping for an estimated RTT. > * For a flow with 1/10 or 1/100 of this RTT (e.g. from a CDN or your > home media server), any congestion signal is delayed tens or hundreds > of its own RTTs by these AQMs. Clearly, RTTs differing by a factor of ten are quite common at most nodes traversed in a typical path; and it seems _very_ suboptimal to have the responsibility for guessing the RTT at the node which must drop packets. > * A TCP flow in slow-start doesn't need the burst smoothed anyway > - delaying the signal just makes slow-start overshoot more > - a TCP in slow-start knows that it won't allow the burst to > dissipate anyway A critical point! (It seems obvious to me, but is it obvious to everyone?) > The solution: make ECN also mean "Immediate Congestion Notification"? > * For ECN-capable packets, shift the job of hiding bursts from network to > host: > - the network signals ECN with no smoothing delay > - then the transport can hide bursts of ECN signals from itself But can we get there from here? The node doing the ECN notification _can't_ know how the transport will react; and the transport receiving and ECN notification can't know whether the forwarding node has "smoothed" the signal. (It is truly a shame we haven't left any bits for signals like this!) > - the transport knows > o whether it's TCP or RTP etc, > o whether its in congestion avoidance or slow-start, > o and it knows its RTT, > o so it can know whether to respond immediately or to smooth the > signals, > o and if so, over what time Yes, but it can't know what smoothing may already have been applied. > - then short RTT flows can smooth the signals with only the delay > of their /own/ RTT > o so they can fill troughs and absorb peaks that longer RTT flows cannot > - a TCP only needs to smooth the signals if in congestion avoidance > o in slow start, it can respond immediately, thus reducing overshoot This would, IMHO, improve "slow start". > Incremental Deployment: > * Immediate congestion notification doesn't need new AQM implementation > - it can use the widely implemented WRED algorithm with an > unexpected configuration Bob is beginning to lose me here. Does he mean that a forwarding node would apply WRED for both drop and ECN, but with different parameters? > * The network classifies packets for this AQM treatment based on > their ECN-capability > - Without ECN, it smoothes the queue before signalling drops Bob has lost me now -- apparently he doesn't mean different parameters... and I don't recognize this "smoothing" step in WRED. > - With ECN, it signals immediately, without any smoothing delay > - (as today, the operator can still use WRED with the Diffserv field too) (Do we need to confuse this discussion by adding diffserv?) > * For TCP apps, the stack will use 'DCTCP' (we've tweaked it), if the > ends negotiate ECN with the accurate feedback capability. Have we settled on "accurate feedback" already? I thought that was still under discussion. (I don't follow exactly what it adds...) > * It should 'just work' if an RTP app or a Reno TCP uses ECN. I don't see any way for a Reno transport using ECN to avoid being starved if ECN arrives earlier (without notice). > The request: > * Much more evaluation to do, but first we want to know: > - if the idea works, would the IETF have an appetite for tweaking > the definition of ECN so it is merely equivalent to drop in the long > term, but the dynamics need not be equivalent. There's a good question there; but I don't think we're ready for it. I'd really like to discuss the dynamics of responding more quickly but perhaps less drastically for almost any real-time flow. But proving "equivalence in the long term" seems too hard. > Much better than the ECN that didn't get deployed > * This is Explicit and Immediate Congestion Notification (EICN?) > - same wire protocol, much greater benefits > * The advantage of the original ECN (avoiding congestive loss) was > too small to be worth the deployment hassle Actually, I don't agree that was the problem -- instead I believe the code has been deployed but administratively suppressed because the operators don't trust the transports. There _is_ a significant improvement from one-RTT reaction instead of several (to detect a drop), but the whole process is just too complicated, while the opportunity for abuse remains obvious. > * Predictable ultra-low latency without loss too (similar to > DCTCP-ECN) would be worth deploying I'm optimistic that latency will become an easier argument. > * But we all thought DCTCP could only be deployed in isolation (e.g. > data centres) > - we all thought DCTCP traffic would starve alongside today's TCP traffic > - because in a DCTCP queue, the ECN threshold is lower than you > would trigger drop > - and we thought ECN & drop had to be equivalent. (I'm not sure we'll succeed at breaking that "equivalence"...) > * We believe we've found a way to ensure DCTCP-ECN traffic doesn't starve > - we still make DCTCP-ECN equivalent to drop in the long-run, but > not in its dynamics (I'm still not sure it's worth arguing the "long-run".) -- John Leslie From rs@netapp.com Sat Oct 26 15:42:29 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A303221F9F0A; Sat, 26 Oct 2013 15:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLn6SNHxAA4v; Sat, 26 Oct 2013 15:42:25 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9CA21F8319; Sat, 26 Oct 2013 15:42:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,578,1378882800"; d="scan'208";a="53101918" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx2-out.netapp.com with ESMTP; 26 Oct 2013 15:42:24 -0700 Received: from SACEXCMBX02-PRD.hq.netapp.com ([169.254.1.86]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.03.0123.003; Sat, 26 Oct 2013 15:42:24 -0700 From: "Scheffenegger, Richard" To: John Leslie , Bob Briscoe Thread-Topic: [aqm] [tsvwg] Immediate and Explicit Congestion Notification (was: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP) Thread-Index: AQHO0kWRNdZgBsOVl06FWzWNER6BB5oHkc6Q Date: Sat, 26 Oct 2013 22:42:23 +0000 Message-ID: <012C3117EDDB3C4781FD802A8C27DD4F25E42144@SACEXCMBX02-PRD.hq.netapp.com> References: <201309171233.r8HCXKkV003952@bagheera.jungle.bt.co.uk> <201310212340.r9LNee5p025162@bagheera.jungle.bt.co.uk> <657D1484-1B02-41F5-9FD1-0921439DF754@isoc.org> <201310252116.r9PLGAFp007348@bagheera.jungle.bt.co.uk> <20131026121632.GJ65952@verdi> In-Reply-To: <20131026121632.GJ65952@verdi> Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "aqm@ietf.org" , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Immediate and Explicit Congestion Notification (was: Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 22:42:29 -0000 HI John, (aqm chair hat off, and accecn author hat on) >> * For TCP apps, the stack will use 'DCTCP' (we've tweaked it), if the >> ends negotiate ECN with the accurate feedback capability. >=20 > Have we settled on "accurate feedback" already? I thought that was > still under discussion. (I don't follow exactly what it adds...) The current requirements draft give a concise list of what benefits it shou= ld bring. There is also the (individual) draft on the TCP ECN modifications, that try= to deliver these benefits within the confines of the TCP header without re= quiring additional bits. The main issue with traditional ECN/TCP is, that you only get one bit of in= formation per RTT (delivered over N segments sent in an RTT), thus the exte= nt of congestion (number of CE marks per this flows RTT), and the fine-grai= ned sequencing of the marks is lost. AccECN aims to deliver these two signals to the sender - but what the sende= r is then doing exactly with this much more detailed information is out of = scope for the AccECN drafts so far. http://tools.ietf.org/html/draft-ietf-tcpm-accecn-reqs http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn ( http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn-option ) Any feedback on these drafts during the TCPM session is appreciated. Richard Scheffenegger From bob.briscoe@bt.com Sun Oct 27 18:36:53 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C997011E82EA; Sun, 27 Oct 2013 18:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[AWL=-1.335, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Clns4-sk8n3n; Sun, 27 Oct 2013 18:36:48 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id EF21111E82DF; Sun, 27 Oct 2013 18:36:45 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 28 Oct 2013 01:36:40 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 28 Oct 2013 01:36:43 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Mon, 28 Oct 2013 01:36:43 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.144.88]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9S1afJ0018887; Mon, 28 Oct 2013 01:36:41 GMT Message-ID: <201310280136.r9S1afJ0018887@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Oct 2013 01:36:39 +0000 To: John Leslie From: Bob Briscoe In-Reply-To: <20131026121632.GJ65952@verdi> References: <201309171233.r8HCXKkV003952@bagheera.jungle.bt.co.uk> <201310212340.r9LNee5p025162@bagheera.jungle.bt.co.uk> <657D1484-1B02-41F5-9FD1-0921439DF754@isoc.org> <201310252116.r9PLGAFp007348@bagheera.jungle.bt.co.uk> <20131026121632.GJ65952@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "aqm@ietf.org" , tsvwg IETF list Subject: Re: [tsvwg] [aqm] Immediate and Explicit Congestion Notification X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 01:36:54 -0000 John, inline... At 12:16 26/10/2013, John Leslie wrote: >Bob Briscoe wrote: > > > > Exec summary > > * Early tests show promise that we may have found a way to make the > > ultra-low queuing delay of data centre TCP incrementally deployable > > on the public Internet > > * For rtcweb, we need to address > > a) cc for r-t media [rmcat w-g in progress] > > b) Making TCP nicer > > c) minimise ability of TCP to bloat queues [AQM w-g now in progress] > > This addresses b) & c) > > > > The problem > > * All AQMs delay dropping for about one (hard-coded) worst-case RTT, > > in case a burst dissipates (allegedly a 'good queue' according to Van > > Jacobson) > > This assertion is going to need a lot of support. > > Bob is a man after my own heart suggesting that an ECN notification >may be sent earlier than a packet drop would be indicated. I don't know >if we can get there; but IMHO that is essential to getting ECN deployed >and used. > > I don't think I agree with Bob that what's hard-coded is necessarily >a "worst-case" RTT -- and I'm quite sure I'm not willing to make any >pronouncement about "all AQMs". > > I suggest the talk might be more useful if Bob outlined the AQMs >currently in widespread use and detailed _how_ they delay dropping >for an estimated RTT. You're right. The 'about' in my sentence was meant to indicate some leeway. The specifics depend on each AQM... The only AQM I know of that doesn't smooth over some nominal RTT is DCTCP itself. * CoDel was designed for 'interval' to be a worst-case (largest) RTT, which it recommends to be set to 100ms. One the queue has exceeded threshold, CoDel delays for time 'interval' before starting to signal congestion. - I already said how sluggish CoDel would be for a flow with a much shorter RTT than CoDel (others have made this point, e.g. for data centres : https://lists.bufferbloat.net/pipermail/codel/2012-August/000448.html). - And in the other direction, we already know that utilisation suffers fairly badly for flows with RTT significantly larger than 100ms. * PIE suppresses all drops for time max_burst (set to 100ms by default) from when the drop probability it calculates (but doesn't necessarily use) first rises above zero. This is very similar to CoDel, and similar comments are applicable. * RED requires the constant for its exponentially weighted moving average (w_q) to be set taking into account how many packets are likely to arrive at the link in a 'typical' RTT. Reverse engineering the values recommended by Sally Floyd in the RED paper and in her famous RED parameters Web page , she recommended a 'typical' RTT of about 130ms. [BTW, I know of people who don't calculate w_q, but just use the value of "0.002" that Sally recommended for her 45Mb/s link in the original RED paper simulations (and repeated at ). This was calculated assuming about 500 packets arrive at a link (from all flows) in a typical RTT. Links have got a lot faster since 1993. Nonetheless, she was considering 45Mb/s for an aggregated link in those days, and it happens to be about right for a single user today.] > > * For a flow with 1/10 or 1/100 of this RTT (e.g. from a CDN or your > > home media server), any congestion signal is delayed tens or hundreds > > of its own RTTs by these AQMs. > > Clearly, RTTs differing by a factor of ten are quite common at most >nodes traversed in a typical path; and it seems _very_ suboptimal to >have the responsibility for guessing the RTT at the node which must >drop packets. For packets that do not support ECN, the dropping node has to make a guess at the RTT, so as not to drop packets unnecessarily, because drop is an impairment as well as a congestion signal. So a transport cannot 'undrop' packets. Our point though is that a network node doesn't have to mimic this behaviour for ECN packets, because ECN is not an impairment. So a transport can un-ECN-mark packets (by smoothing out bursts itself). > > * A TCP flow in slow-start doesn't need the burst smoothed anyway > > - delaying the signal just makes slow-start overshoot more > > - a TCP in slow-start knows that it won't allow the burst to > > dissipate anyway > > A critical point! (It seems obvious to me, but is it obvious to >everyone?) > > > The solution: make ECN also mean "Immediate Congestion Notification"? > > * For ECN-capable packets, shift the job of hiding bursts from network to > > host: > > - the network signals ECN with no smoothing delay > > - then the transport can hide bursts of ECN signals from itself > > But can we get there from here? > > The node doing the ECN notification _can't_ know how the transport >will react; and the transport receiving and ECN notification can't know >whether the forwarding node has "smoothed" the signal. (It is truly a >shame we haven't left any bits for signals like this!) Well, we do have ECT(1) still only assigned experimentally and never used, which we could decide to use for this immediate ECN. However, first I want to see whether people think it might be feasible to just redefine the meaning of CE. Rationale: So few buffers have ECN support turned on anyway that we should be able to redefine ECN so that many more will want to turn it on. For those AQMs that already support ECN, we believe this retrospective change will make them only a little worse than they are already (and the operator can update them by simple reconfiguration anyway, and is more likely to do so, given these are clearly early-adopter networks). > > - the transport knows > > o whether it's TCP or RTP etc, > > o whether its in congestion avoidance or slow-start, > > o and it knows its RTT, > > o so it can know whether to respond immediately or to smooth the > > signals, > > o and if so, over what time > > Yes, but it can't know what smoothing may already have been applied. Yes. If this is a problem, we will have to consider using ECT(1) not CE. But it's pretty academic when so few buffers support ECN. The tiny proportion that do support ECN will already smooth by a 'typical RTT' of about 100ms. If a 20ms RTT flow adds smoothing over its own RTT to this, it will be smooth over 120ms. The main problem there is not the extra 20ms, it's the original 100ms, which we won't lose unless we make this change somehow. > > - then short RTT flows can smooth the signals with only the delay > > of their /own/ RTT > > o so they can fill troughs and absorb peaks that longer RTT > flows cannot > > - a TCP only needs to smooth the signals if in congestion avoidance > > o in slow start, it can respond immediately, thus reducing overshoot > > This would, IMHO, improve "slow start". > > > Incremental Deployment: > > * Immediate congestion notification doesn't need new AQM implementation > > - it can use the widely implemented WRED algorithm with an > > unexpected configuration > > Bob is beginning to lose me here. Does he mean that a forwarding node >would apply WRED for both drop and ECN, but with different parameters? > > > * The network classifies packets for this AQM treatment based on > > their ECN-capability > > - Without ECN, it smoothes the queue before signalling drops > > Bob has lost me now -- apparently he doesn't mean different >parameters... and I don't recognize this "smoothing" step in WRED. I do mean that a forwarding node would apply WRED for both drop and ECN, but with different parameters. Each WRED policy-map includes a setting for this smoothing parameter, which Cisco calls the exponential-weighting-constant. Many people don't notice it's there and they just leave it at the default. For instance, Cisco set it to 2^(-9) ~ 0.002 by default for each of the WRED policy-maps (see http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fswfq26.html#wp1039982). > > - With ECN, it signals immediately, without any smoothing delay > > - (as today, the operator can still use WRED with the Diffserv field too) > > (Do we need to confuse this discussion by adding diffserv?) A non-Diffserv network still doesn't need to worry about Diffserv. I put this in parentheses because, if WRED is used today, it is usually used with Diffserv, and I didn't want anyone to worry that they wouldn't be able to continue to do this (e.g. BT use WRED with Diffserv in enterprise networks, as do many other carriers). > > * For TCP apps, the stack will use 'DCTCP' (we've tweaked it), if the > > ends negotiate ECN with the accurate feedback capability. > > Have we settled on "accurate feedback" already? I thought that was >still under discussion. (I don't follow exactly what it adds...) See response from Richard Scheffenegger. Essentially the TCPM WG has accepted the requirements doc, but not decided between the mechanisms on offer. > > * It should 'just work' if an RTP app or a Reno TCP uses ECN. > > I don't see any way for a Reno transport using ECN to avoid being >starved if ECN arrives earlier (without notice). We haven't tested legacy Reno with ECN yet (we figured legacy Reno without ECN is a lot more prevalent, so focused on this first). Nonetheless, Reno-ECN is unlikely to starve, because starvation is about long-running behaviour, and once a flow has run for more than a couple of 100ms RTTs, the immediate ECN signals should be no different from a smoothed ECN. I suspect Reno-ECN might be worse in its short-term dynamics. But remember Reno-ECN is likely to be a tiny corner-case. > > The request: > > * Much more evaluation to do, but first we want to know: > > - if the idea works, would the IETF have an appetite for tweaking > > the definition of ECN so it is merely equivalent to drop in the long > > term, but the dynamics need not be equivalent. > > There's a good question there; but I don't think we're ready for it. At this stage, even we haven't got many answers. So I'm not asking the IETF to answer the question right now. I'm merely saying, /if/ our idea works, is there at least an /appetite/ in the IETF for reconsidering the definition of ECN? We wanted to make the IETF aware of this research early, because it might want to at least hold off on any actions that would otherwise close off this option. And if we find that any change is completely out of the question, we have to try a different tack (e.g. ECT(1)). > I'd really like to discuss the dynamics of responding more quickly >but perhaps less drastically for almost any real-time flow. > > But proving "equivalence in the long term" seems too hard. This should be the easy part, because the longer that conditions are stable, a smoothed signal should tend towards an unsmoothed signal, all other factors being equal. Equivalence during dynamics is the hard part, and I'm suggesting we don't sweat too much about that, as long as the performance evaluations are not too far apart. > > Much better than the ECN that didn't get deployed > > * This is Explicit and Immediate Congestion Notification (EICN?) > > - same wire protocol, much greater benefits > > * The advantage of the original ECN (avoiding congestive loss) was > > too small to be worth the deployment hassle > > Actually, I don't agree that was the problem -- instead I believe >the code has been deployed but administratively suppressed because >the operators don't trust the transports. There _is_ a significant >improvement from one-RTT reaction instead of several (to detect a >drop), but the whole process is just too complicated, while the >opportunity for abuse remains obvious. I agree. That's the 'deployment hassle' side of my sentence - the extra trust-enhancing mechanisms that seemed necessary were too much pain for the small gain. > > * Predictable ultra-low latency without loss too (similar to > > DCTCP-ECN) would be worth deploying > > I'm optimistic that latency will become an easier argument. > > > * But we all thought DCTCP could only be deployed in isolation (e.g. > > data centres) > > - we all thought DCTCP traffic would starve alongside today's TCP traffic > > - because in a DCTCP queue, the ECN threshold is lower than you > > would trigger drop > > - and we thought ECN & drop had to be equivalent. > > (I'm not sure we'll succeed at breaking that "equivalence"...) > > > * We believe we've found a way to ensure DCTCP-ECN traffic doesn't starve > > - we still make DCTCP-ECN equivalent to drop in the long-run, but > > not in its dynamics > > (I'm still not sure it's worth arguing the "long-run".) I mean competing long-running ECN & non-ECN flows stabilise at predictable rates, rather than one ratchetting itself down to nothing over time (starvation). That's the primary concern of congestion control 'fairness', before anyone starts worrying about what the relative rates are. Given apps get different relative rates with different RTTs, with different size objects or by opening multiple flows, we don't need to sweat so much about precisely equal flow rates; but we must sweat about stable convergence. Results so far show that the proposed idea is at least very robust against starvation. Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT From dave.taht@gmail.com Sun Oct 27 21:22:32 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE9D11E814B; Sun, 27 Oct 2013 21:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut-lDglbL0Em; Sun, 27 Oct 2013 21:22:30 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A8B5611E80F2; Sun, 27 Oct 2013 21:22:29 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id q59so5924944wes.23 for ; Sun, 27 Oct 2013 21:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RITAgogiFx/sU7NzueW0IH7j4Ape3mjwuyKPuD1JUTU=; b=vf5htJyzkc7DvZxEy21VcQRJfkrqXB2KkSMOOV6BmVXeBY4pDK8e1qmgqOlV1bFQuh u6NW4Bv9GPyuu1D2exk9ib7+sNxecDd8PKnsnISxGZNq3SN+KCqC6GGOhTLHzf2ynAzo t2o6En80n8VdiiP3thJxgxArc/JjUyNDtsxcXfz/PdF6oLSR6w3MQcY/hkYCYU7aqd1P P2H1s+s9K5Hl1Vul3RhDUMlc4LKCmO/MsKunwklQ/t3SpPrPlDeBIBmlErHlu8OHLbam eIZnOlln7YprfCIdmQS13qBD/PnIE+o9MTO7ruToVsVln1qlJvUz7PKoYHBpoclT8lZN ujZg== MIME-Version: 1.0 X-Received: by 10.180.13.113 with SMTP id g17mr7337187wic.19.1382934148568; Sun, 27 Oct 2013 21:22:28 -0700 (PDT) Received: by 10.217.67.202 with HTTP; Sun, 27 Oct 2013 21:22:28 -0700 (PDT) In-Reply-To: <201310280136.r9S1afJ0018887@bagheera.jungle.bt.co.uk> References: <201309171233.r8HCXKkV003952@bagheera.jungle.bt.co.uk> <201310212340.r9LNee5p025162@bagheera.jungle.bt.co.uk> <657D1484-1B02-41F5-9FD1-0921439DF754@isoc.org> <201310252116.r9PLGAFp007348@bagheera.jungle.bt.co.uk> <20131026121632.GJ65952@verdi> <201310280136.r9S1afJ0018887@bagheera.jungle.bt.co.uk> Date: Sun, 27 Oct 2013 21:22:28 -0700 Message-ID: From: Dave Taht To: Bob Briscoe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tsvwg IETF list , "aqm@ietf.org" Subject: Re: [tsvwg] [aqm] Immediate and Explicit Congestion Notification X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 04:22:32 -0000 As is probably well known at this point, I make a clear distinction between networking problems in the data center and ones in the wild and wooly world. The data center portion of the universe is a couple hundred meters in diameter, the other, I dunno, let's say 8x from here to the moon (3,075,200,000m). There are all sorts of things that work and are needed in the data center that probably won't work outside it. People run straighter cables, do microwave, use pause frames at layer 2, etc, etc, in order to wring out the last nanosecond of performance, and certainly running without loss is important in that world. On Sun, Oct 27, 2013 at 6:36 PM, Bob Briscoe wrote: > John, inline... > > At 12:16 26/10/2013, John Leslie wrote: >> >> Bob Briscoe wrote: >> > >> > Exec summary >> > * Early tests show promise that we may have found a way to make the I'm failing to get excited lacking paper, testable code, and other proofs. >> > ultra-low queuing delay of data centre TCP incrementally deployable >> > on the public Internet At the moment the edge of the internet is using things like cable and gpon which have 2ms or more of inherent latency built into their grant/response structures. >> > * For rtcweb, we need to address >> > a) cc for r-t media [rmcat w-g in progress] >> > b) Making TCP nicer >> > c) minimise ability of TCP to bloat queues [AQM w-g now in progress] >> > This addresses b) & c) I do strongly feel that webrtc needs good aqm and packet scheduling in order to succeed, and that the webrtc folk should be testing out what has already been developed (red, sfqred, codel, fq_codel, pie) and the aqm folk testing the webrtc code. I look forward to some interesting conference calls. I gave the webrtc codebases a whirl against what aqm and packet scheduling techniques we have already this past summer, the initial results were encouraging, but I was able to easily crash most of the browsers sooner than I could take a good, repeatable set of measurements. That said, things over there are moving along smartly. >> > >> > The problem >> > * All AQMs delay dropping for about one (hard-coded) worst-case RTT, >> > in case a burst dissipates (allegedly a 'good queue' according to Van >> > Jacobson) >> >> This assertion is going to need a lot of support. >> >> Bob is a man after my own heart suggesting that an ECN notification >> may be sent earlier than a packet drop would be indicated. I don't know >> if we can get there; but IMHO that is essential to getting ECN deployed >> and used. >> >> I don't think I agree with Bob that what's hard-coded is necessarily >> a "worst-case" RTT -- and I'm quite sure I'm not willing to make any >> pronouncement about "all AQMs". >> >> I suggest the talk might be more useful if Bob outlined the AQMs >> currently in widespread use and detailed _how_ they delay dropping >> for an estimated RTT. > > > You're right. The 'about' in my sentence was meant to indicate some leewa= y. > The specifics depend on each AQM... > > The only AQM I know of that doesn't smooth over some nominal RTT is DCTCP > itself. DCTCP fits uncomfortably into the aqm catagory. > > * CoDel was designed for 'interval' to be a worst-case (largest) RTT, whi= ch > it recommends to be set to 100ms. One the queue has exceeded threshold, Which is 5ms of delay. > CoDel delays for time 'interval' before starting to signal congestion. Which it then decreases until it finds something approximating the RTT. For a system in a reasonably steady state, it will find a decent value and stay there. For bursty traffic it is not necessarily helpful, and slow start is interesting... > - I already said how sluggish CoDel would be for a flow with a much shor= ter But you've never published a measurement, unless there is one in your new p= aper? > RTT than CoDel (others have made this point, e.g. for data centres : > https://lists.bufferbloat.net/pipermail/codel/2012-August/000448.html). You might want to read the full thread... a stumbling block on fixing the srtt was the stochastic hashing... so now there is a full blown non-approximated fq scheduler that implements pacing. http://www.ietf.org/mail-archive/web/aqm/current/msg00259.html And I look forward to a certain upcoming presentation in ICCRG with great anticipation as to additional fallout from this.... > - And in the other direction, we already know that utilisation suffers > fairly badly for flows with RTT significantly larger than 100ms. "target" and "interval" have always been variables in the fq_codel and codel codebase and ecn is supported. tc qdisc add dev your_device root fq_codel target 500us interval 10ms ecn I don't think the pain of adding that one line of configuration would affect a data center deployment any. I would certainly like to see benchmarks in a data center environment. I personally lack 10Gig hw. I note that once you get below 1ms on a typical box today, you start hitting other bottlenecks in (for example) the cpu scheduler. > * PIE suppresses all drops for time max_burst (set to 100ms by default) f= rom > when the drop probability it calculates (but doesn't necessarily use) fir= st > rises above zero. This is very similar to CoDel, and similar comments are > applicable. This too has a variable target value, although there are several other magic constants that I don't fully understand. I would certainly like to see some benchmarks in a data center environment. The pie code I have for linux shoots for a target of 20ms by default, for some reason. > * RED requires the constant for its exponentially weighted moving average > (w_q) to be set taking into account how many packets are likely to arrive= at > the link in a 'typical' RTT. Reverse engineering the values recommended b= y > Sally Floyd in the RED paper and in her famous RED parameters Web page > , she recommended a 'typical= ' > RTT of about 130ms. > > [BTW, I know of people who don't calculate w_q, but just use the value of > "0.002" that Sally recommended for her 45Mb/s link in the original RED pa= per > simulations (and repeated at ). > This was calculated assuming about 500 packets arrive at a link (from all > flows) in a typical RTT. Links have got a lot faster since 1993. > Nonetheless, she was considering 45Mb/s for an aggregated link in those > days, and it happens to be about right for a single user today.] > > >> > * For a flow with 1/10 or 1/100 of this RTT (e.g. from a CDN or your >> > home media server), any congestion signal is delayed tens or hundreds >> > of its own RTTs by these AQMs. Congestion takes time to occur. Consider tcp dynamics as flows also only increase relative to RTT, as well. A core question is what do you want response time to congestion to be under= ? 100ms? 5ms? 1ms? 500us? >> Clearly, RTTs differing by a factor of ten are quite common at most >> nodes traversed in a typical path; and it seems _very_ suboptimal to 2.4 billion folk connect to the internet generally at RTTs between 20 and 8= 0ms. In a data center environment I have no data. >> have the responsibility for guessing the RTT at the node which must >> drop packets. I certainly favor the ongoing development of end to end cc capable of monitoring the RTT and doing the right thing. > For packets that do not support ECN, the dropping node has to make a gues= s > at the RTT, so as not to drop packets unnecessarily, because drop is an > impairment as well as a congestion signal. So a transport cannot 'undrop' > packets. > > Our point though is that a network node doesn't have to mimic this behavi= our > for ECN packets, because ECN is not an impairment. So a transport can > un-ECN-mark packets (by smoothing out bursts itself). > > >> > * A TCP flow in slow-start doesn't need the burst smoothed anyway >> > - delaying the signal just makes slow-start overshoot more >> > - a TCP in slow-start knows that it won't allow the burst to >> > dissipate anyway The end of slow start is an ECN notification or a packet drop. What am I missing here? >> A critical point! (It seems obvious to me, but is it obvious to >> everyone?) >> >> > The solution: make ECN also mean "Immediate Congestion Notification"? >> > * For ECN-capable packets, shift the job of hiding bursts from network >> > to >> > host: >> > - the network signals ECN with no smoothing delay >> > - then the transport can hide bursts of ECN signals from itself >> >> But can we get there from here? >> >> The node doing the ECN notification _can't_ know how the transport >> will react; and the transport receiving and ECN notification can't know >> whether the forwarding node has "smoothed" the signal. (It is truly a >> shame we haven't left any bits for signals like this!) > > > Well, we do have ECT(1) still only assigned experimentally and never used= , > which we could decide to use for this immediate ECN. However, first I wan= t > to see whether people think it might be feasible to just redefine the > meaning of CE. A lot of the NONCE logic has been discussed in other rfcs. > > Rationale: So few buffers have ECN support turned on anyway that we shoul= d > be able to redefine ECN so that many more will want to turn it on. > > For those AQMs that already support ECN, we believe this retrospective > change will make them only a little worse than they are already (and the > operator can update them by simple reconfiguration anyway, and is more > likely to do so, given these are clearly early-adopter networks). > > >> > - the transport knows >> > o whether it's TCP or RTP etc, >> > o whether its in congestion avoidance or slow-start, >> > o and it knows its RTT, >> > o so it can know whether to respond immediately or to smooth the >> > signals, >> > o and if so, over what time >> >> Yes, but it can't know what smoothing may already have been applied. > > > Yes. If this is a problem, we will have to consider using ECT(1) not CE. > But it's pretty academic when so few buffers support ECN. > > The tiny proportion that do support ECN will already smooth by a 'typical > RTT' of about 100ms. > > If a 20ms RTT flow adds smoothing over its own RTT to this, it will be > smooth over 120ms. > The main problem there is not the extra 20ms, it's the original 100ms, wh= ich > we won't lose unless we make this change somehow. > > >> > - then short RTT flows can smooth the signals with only the delay >> > of their /own/ RTT >> > o so they can fill troughs and absorb peaks that longer RTT flows >> > cannot >> > - a TCP only needs to smooth the signals if in congestion avoidance >> > o in slow start, it can respond immediately, thus reducing oversho= ot >> >> This would, IMHO, improve "slow start". >> >> > Incremental Deployment: >> > * Immediate congestion notification doesn't need new AQM implementatio= n >> > - it can use the widely implemented WRED algorithm with an >> > unexpected configuration >> >> Bob is beginning to lose me here. Does he mean that a forwarding node >> would apply WRED for both drop and ECN, but with different parameters? >> >> > * The network classifies packets for this AQM treatment based on >> > their ECN-capability >> > - Without ECN, it smoothes the queue before signalling drops >> >> Bob has lost me now -- apparently he doesn't mean different >> parameters... and I don't recognize this "smoothing" step in WRED. > > > I do mean that a forwarding node would apply WRED for both drop and ECN, = but > with different parameters. > > Each WRED policy-map includes a setting for this smoothing parameter, whi= ch > Cisco calls the exponential-weighting-constant. Many people don't notice > it's there and they just leave it at the default. For instance, Cisco set= it > to > 2^(-9) ~ 0.002 by default for each of the WRED policy-maps (see > http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fswfq26.html#wp10= 39982). > > >> > - With ECN, it signals immediately, without any smoothing delay >> > - (as today, the operator can still use WRED with the Diffserv field >> > too) >> >> (Do we need to confuse this discussion by adding diffserv?) > > > A non-Diffserv network still doesn't need to worry about Diffserv. > > I put this in parentheses because, if WRED is used today, it is usually u= sed > with Diffserv, and I didn't want anyone to worry that they wouldn't be ab= le > to continue to do this (e.g. BT use WRED with Diffserv in enterprise > networks, as do many other carriers). Perhaps we need a taxonomy so we can all talk to areas of the network we care about? RED as currently defined will not work correctly on variable rate networks, like wireless... I have never thought we'd end up with one aqm or tcp to rule them all.. DC: Data Center WI: Wireless FL: Fixed Line > >> > * For TCP apps, the stack will use 'DCTCP' (we've tweaked it), if the >> > ends negotiate ECN with the accurate feedback capability. >> >> Have we settled on "accurate feedback" already? I thought that was >> still under discussion. (I don't follow exactly what it adds...) > > > See response from Richard Scheffenegger. Essentially the TCPM WG has > accepted the requirements doc, but not decided between the mechanisms on > offer. > > >> > * It should 'just work' if an RTP app or a Reno TCP uses ECN. >> >> I don't see any way for a Reno transport using ECN to avoid being >> starved if ECN arrives earlier (without notice). > > > We haven't tested legacy Reno with ECN yet (we figured legacy Reno withou= t > ECN is a lot more prevalent, so focused on this first). Nonetheless, > Reno-ECN is unlikely to starve, because starvation is about long-running > behaviour, and once a flow has run for more than a couple of 100ms RTTs, = the > immediate ECN signals should be no different from a smoothed ECN. I suspe= ct > Reno-ECN might be worse in its short-term dynamics. But remember Reno-ECN= is > likely to be a tiny corner-case. > > >> > The request: >> > * Much more evaluation to do, but first we want to know: >> > - if the idea works, would the IETF have an appetite for tweaking >> > the definition of ECN so it is merely equivalent to drop in the long >> > term, but the dynamics need not be equivalent. >> >> There's a good question there; but I don't think we're ready for it. > > > At this stage, even we haven't got many answers. So I'm not asking the IE= TF > to answer the question right now. I'm merely saying, /if/ our idea works,= is > there at least an /appetite/ in the IETF for reconsidering the definition= of > ECN? I wouldn't mind it, but frankly my own concern was addressing the security issue, not the current definition. > We wanted to make the IETF aware of this research early, because it might > want to at least hold off on any actions that would otherwise close off t= his > option. > > And if we find that any change is completely out of the question, we have= to > try a different tack (e.g. ECT(1)). > > >> I'd really like to discuss the dynamics of responding more quickly >> but perhaps less drastically for almost any real-time flow. >> >> But proving "equivalence in the long term" seems too hard. > > > This should be the easy part, because the longer that conditions are stab= le, > a smoothed signal should tend towards an unsmoothed signal, all other > factors being equal. > > Equivalence during dynamics is the hard part, and I'm suggesting we don't > sweat too much about that, as long as the performance evaluations are not > too far apart. > > >> > Much better than the ECN that didn't get deployed >> > * This is Explicit and Immediate Congestion Notification (EICN?) >> > - same wire protocol, much greater benefits >> > * The advantage of the original ECN (avoiding congestive loss) was >> > too small to be worth the deployment hassle >> >> Actually, I don't agree that was the problem -- instead I believe >> the code has been deployed but administratively suppressed because >> the operators don't trust the transports. There _is_ a significant >> improvement from one-RTT reaction instead of several (to detect a >> drop), but the whole process is just too complicated, while the >> opportunity for abuse remains obvious. > > > I agree. That's the 'deployment hassle' side of my sentence - the extra > trust-enhancing mechanisms that seemed necessary were too much pain for t= he > small gain. I > > >> > * Predictable ultra-low latency without loss too (similar to >> > DCTCP-ECN) would be worth deploying >> >> I'm optimistic that latency will become an easier argument. >> >> > * But we all thought DCTCP could only be deployed in isolation (e.g. >> > data centres) >> > - we all thought DCTCP traffic would starve alongside today's TCP >> > traffic >> > - because in a DCTCP queue, the ECN threshold is lower than you >> > would trigger drop >> > - and we thought ECN & drop had to be equivalent. I'm looking forward to being convinced otherwise. >> (I'm not sure we'll succeed at breaking that "equivalence"...) >> >> > * We believe we've found a way to ensure DCTCP-ECN traffic doesn't >> > starve >> > - we still make DCTCP-ECN equivalent to drop in the long-run, but >> > not in its dynamics >> >> (I'm still not sure it's worth arguing the "long-run".) > > > I mean competing long-running ECN & non-ECN flows stabilise at predictabl= e > rates, rather than one ratchetting itself down to nothing over time > (starvation). > > That's the primary concern of congestion control 'fairness', before anyon= e > starts worrying about what the relative rates are. Given apps get differe= nt > relative rates with different RTTs, with different size objects or by > opening multiple flows, we don't need to sweat so much about precisely eq= ual > flow rates; but we must sweat about stable convergence. > > Results so far show that the proposed idea is at least very robust agains= t > starvation. > > > Bob > > >> -- >> John Leslie > > > ________________________________________________________________ > Bob Briscoe, BT > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html From bob.briscoe@bt.com Mon Oct 28 00:17:17 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1127411E813D; Mon, 28 Oct 2013 00:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id occOPEMkaL9R; Mon, 28 Oct 2013 00:17:10 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id B7A2A11E81BF; Mon, 28 Oct 2013 00:17:06 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 28 Oct 2013 07:17:04 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 28 Oct 2013 07:17:04 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Mon, 28 Oct 2013 07:16:54 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.109.144.88]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r9S7GoZf020045; Mon, 28 Oct 2013 07:16:51 GMT Message-ID: <201310280716.r9S7GoZf020045@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Oct 2013 07:16:49 +0000 To: Dave Taht From: Bob Briscoe In-Reply-To: References: <201309171233.r8HCXKkV003952@bagheera.jungle.bt.co.uk> <201310212340.r9LNee5p025162@bagheera.jungle.bt.co.uk> <657D1484-1B02-41F5-9FD1-0921439DF754@isoc.org> <201310252116.r9PLGAFp007348@bagheera.jungle.bt.co.uk> <20131026121632.GJ65952@verdi> <201310280136.r9S1afJ0018887@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg IETF list , "aqm@ietf.org" Subject: Re: [tsvwg] [aqm] Immediate and Explicit Congestion Notification X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 07:17:17 -0000 Dave, At 04:22 28/10/2013, Dave Taht wrote: >As is probably well known at this point, I make a clear distinction >between networking problems in the data center and ones in the wild >and wooly world. The two are converging. It will gradually become=20 less sensible to think of the two as separate. >The data center portion of the universe is a couple hundred meters in >diameter, the other, I dunno, let's say 8x from here to the moon >(3,075,200,000m). DCTCP was fixed ages ago for global RTTs.=20 Download the Linux version from Stanford. >There are all sorts of things that work and are needed in the data >center that probably won't work outside it. People run straighter >cables, do microwave, use pause frames at layer 2, etc, etc, in order >to wring out the last nanosecond of performance, and certainly running >without loss is important in that world. Not relevant. Don't be confused by the name=20 DCTCP. It's only a few lines of code different=20 from TCP, and it's not only relevant in data=20 centres. It's for low queuing delay. It's only confined to a data centre while we=20 can't work out how it co-exists with current=20 Internet traffic - that's what we're doing. >On Sun, Oct 27, 2013 at 6:36 PM, Bob Briscoe wrote: > > John, inline... > > > > At 12:16 26/10/2013, John Leslie wrote: > >> > >> Bob Briscoe wrote: > >> > > >> > Exec summary > >> > * Early tests show promise that we may have found a way to make the > >I'm failing to get excited lacking paper, testable code, and other proofs. I'll send the paper, but agreed we've only just=20 got started, so you don't have to be excited yet. A lot more testing to do. > >> > ultra-low queuing delay of data centre TCP incrementally deployable > >> > on the public Internet > >At the moment the edge of the internet is using things like cable and >gpon which have 2ms or more of inherent latency built into their >grant/response structures. You're saying you're not interested in low=20 queuing delay solutions because there's often=20 fluff in badly designed access networks anyway?=20 That sounds like a poor excuse for not aspiring=20 to lower delay. What excuse is there for the=20 100ms of signalling delay on ECN packets in CoDel=20 then? That's 50 times more than this 2ms=20 (currently) inherent access network delay (that=20 some of us are working to remove as well). If you put an AQM in a host that is the=20 bottleneck for a transfer to your media server in=20 the next room of your house, at the same time as=20 transfers to the wide area, you really don't want=20 to introduce a nominal global RTT into both feedback loops. > >> > * For rtcweb, we need to address > >> > a) cc for r-t media [rmcat w-g in progress] > >> > b) Making TCP nicer > >> > c) minimise ability of TCP to bloat queues [AQM w-g now in= progress] > >> > This addresses b) & c) > >I do strongly feel that webrtc needs good aqm and packet scheduling in >order to succeed, and that the webrtc folk should be testing out what >has already been developed (red, sfqred, codel, fq_codel, pie) and the >aqm folk testing the webrtc code. The AQM for DCTCP was developed 2 years before=20 all of those (except RED). Why decide to build on=20 CoDel in 2012, when DCTCP had already been out=20 there and deployed for 2 years with excellent=20 results? And tcp-rcv-cheat had been out there for 5 years. >I look forward to some interesting conference calls. > >I gave the webrtc codebases a whirl against what aqm and packet >scheduling techniques we have already this past summer, the initial >results were encouraging, but I was able to easily crash most of the >browsers sooner than I could take a good, repeatable set of >measurements. That said, things over there are moving along smartly. > > >> > > >> > The problem > >> > * All AQMs delay dropping for about one (hard-coded) worst-case RTT, > >> > in case a burst dissipates (allegedly a 'good queue' according to Van > >> > Jacobson) > >> > >> This assertion is going to need a lot of support. > >> > >> Bob is a man after my own heart suggesting that an ECN notification > >> may be sent earlier than a packet drop would be indicated. I don't know > >> if we can get there; but IMHO that is essential to getting ECN deployed > >> and used. > >> > >> I don't think I agree with Bob that what's hard-coded is necessarily > >> a "worst-case" RTT -- and I'm quite sure I'm not willing to make any > >> pronouncement about "all AQMs". > >> > >> I suggest the talk might be more useful if Bob outlined the AQMs > >> currently in widespread use and detailed _how_ they delay dropping > >> for an estimated RTT. > > > > > > You're right. The 'about' in my sentence was meant to indicate some= leeway. > > The specifics depend on each AQM... > > > > The only AQM I know of that doesn't smooth over some nominal RTT is= DCTCP > > itself. > >DCTCP fits uncomfortably into the aqm catagory. Oh dear. Is this Dave Taht saying "I don't like=20 it cos it's different to tradition"? DCTCP shows just how low you can get queuing=20 delay even with a brain-dead simple step AQM as=20 long as you fix the right problem (smooth in TCP,=20 not in the AQM). Doesn't this tell you something=20 about where the problem probably was? > > > > * CoDel was designed for 'interval' to be a worst-case (largest) RTT,= which > > it recommends to be set to 100ms. One the queue has exceeded threshold, > >Which is 5ms of delay. 105ms of delay on top of RTT delay before it can possibly do anything. By far the most common case on an access link is=20 a flow arriving when the link's empty. > > CoDel delays for time 'interval' before starting to signal congestion. > >Which it then decreases until it finds something approximating the >RTT. For a system in a reasonably steady state, it will find a decent >value and stay there. Until the queue empties (which it should if the=20 control system is working), then it has to start=20 over, because another flow may have a different RTT. >For bursty traffic it is not necessarily helpful, and slow start is >interesting... > > > - I already said how sluggish CoDel would be=20 > for a flow with a much shorter > >But you've never published a measurement, unless=20 >there is one in your new paper? Lots of experiments in the paper, but not the=20 dynamics yet - we deliberately focused on the=20 long-running behaviour first, to check the critical starvation issues first. > > RTT than CoDel (others have made this point, e.g. for data centres : > > https://lists.bufferbloat.net/pipermail/codel/2012-August/000448.html). > >You might want to read the full thread... a stumbling block on fixing >the srtt was the stochastic hashing... so now there is a full blown >non-approximated fq scheduler that implements pacing. > >http://www.ietf.org/mail-archive/web/aqm/current/msg00259.html As I understand it, this only works for an AQM on=20 a host that has the benefit of being told the RTT from higher up the stack. >And I look forward to a certain upcoming presentation in ICCRG with >great anticipation as to additional fallout from this.... > > > - And in the other direction, we already know that utilisation suffers > > fairly badly for flows with RTT significantly larger than 100ms. > >"target" and "interval" have always been variables in the fq_codel and >codel codebase It's not use having variables you don't know how=20 to set. That was the lesson from RED that DCTCP=20 started to solve (concerning variable RTT), and=20 CoDel continued to solve (concerning line=20 variable rate). However, unfortunately CoDel chose the not invented here= route. >and ecn is supported. > >tc qdisc add dev your_device root fq_codel target 500us interval 10ms ecn AFAICT, ECN is only supported in CoDel in the=20 sense that it is treated as equivalent to drop.=20 The factors where ECN is not equivalent to drop have not been catered for. And ECN certainly hasn't been considered as=20 something to exploit beyond what drop can do. For=20 instance, to take the approach I'm suggesting,=20 but using CoDel not RED, for ECN-capable packets=20 you would use interval as zero. Then the=20 end-system would smooth out bursts of ECN marks instead of CoDel doing it. >I don't think the pain of adding that one line of configuration would >affect a data center deployment any. I would certainly like to see >benchmarks in a data center environment. I personally lack 10Gig hw. > >I note that once you get below 1ms on a typical box today, you start >hitting other bottlenecks in (for example) the cpu scheduler. As above, not a good reason. We have to knock=20 down each source of delay, one after the other. > > * PIE suppresses all drops for time max_burst=20 > (set to 100ms by default) from > > when the drop probability it calculates (but doesn't necessarily use)= first > > rises above zero. This is very similar to CoDel, and similar comments= are > > applicable. > >This too has a variable target value, although there are several other >magic constants that I don't fully understand. It takes a few minutes of reading to understand=20 all the PIE variables (about the same complexity=20 as CoDel). I think PIE has the following constants (defaults in []): * target_del (the target queuing delay [20ms] as you say) * max_burst (has a similar role to interval in CoDel [100ms]) * deq_threshold (there's enough packets in the=20 queue to measure the line-rate [10KB]) * Tupdate, which determines how often the line=20 rate is tested (which shouldn't affect=20 performance unless the machine can't cope with a high enough update rate). All the other variables are dependents of these,=20 or autotuned (in the case of alpha and beta). >I would certainly like >to see some benchmarks in a data center environment. Just to be clear, for this conversation I'm not=20 focused on a data centre environment - I'm making=20 DCTCP applicable to the public Internet. >The pie code I >have for linux shoots for a target of 20ms by default, for some >reason. > > > * RED requires the constant for its exponentially weighted moving= average > > (w_q) to be set taking into account how many=20 > packets are likely to arrive at > > the link in a 'typical' RTT. Reverse engineering the values recommended= by > > Sally Floyd in the RED paper and in her famous RED parameters Web page > > , she recommended a= 'typical' > > RTT of about 130ms. > > > > [BTW, I know of people who don't calculate w_q, but just use the value= of > > "0.002" that Sally recommended for her 45Mb/s=20 > link in the original RED paper > > simulations (and repeated at=20 > ). > > This was calculated assuming about 500 packets arrive at a link (from= all > > flows) in a typical RTT. Links have got a lot faster since 1993. > > Nonetheless, she was considering 45Mb/s for an aggregated link in those > > days, and it happens to be about right for a single user today.] > > > > > >> > * For a flow with 1/10 or 1/100 of this RTT (e.g. from a CDN or your > >> > home media server), any congestion signal is delayed tens or hundreds > >> > of its own RTTs by these AQMs. > >Congestion takes time to occur. Consider tcp dynamics as flows also >only increase relative to RTT, as well. Er no. As a queue builds, it causes delay.=20 Regular TCP makes this worse than it has to be by=20 using large saw-teeth, so they become a large=20 inherent variable source of delay. VJ calls this=20 a good queue. But if a variant of TCP can remove=20 this variable source of delay, it can't be good. >A core question is what do you want response time to congestion to be= under? > >100ms? 5ms? 1ms? 500us? Wrong question. Answer depends on RTT. That's the=20 whole point. Consider that you may have been brain-washed. > >> Clearly, RTTs differing by a factor of ten are quite common at most > >> nodes traversed in a typical path; and it seems _very_ suboptimal to > >2.4 billion folk connect to the internet=20 >generally at RTTs between 20 and 80ms. The Internet includes your home network,=20 potentially a cache in your home gateway, I/O=20 lanes within your own machine, etc etc. No-one=20 "connects to the Internet at an RTT of" anything.=20 Today, all these 2.4B folk use connections over=20 the Internet with a very wide range of RTTs. >In a data center environment I have no data. Typically 100us or 200us base RTT. And all that=20 cheap data centre kit can be and will be re-used in the public Internet too. > >> have the responsibility for guessing the RTT at the node which must > >> drop packets. > >I certainly favor the ongoing development of end to end cc capable of >monitoring the RTT and doing the right thing. Good. > > For packets that do not support ECN, the dropping node has to make a= guess > > at the RTT, so as not to drop packets unnecessarily, because drop is an > > impairment as well as a congestion signal. So a transport cannot= 'undrop' > > packets. > > > > Our point though is that a network node=20 > doesn't have to mimic this behaviour > > for ECN packets, because ECN is not an impairment. So a transport can > > un-ECN-mark packets (by smoothing out bursts itself). > > > > > >> > * A TCP flow in slow-start doesn't need the burst smoothed anyway > >> > - delaying the signal just makes slow-start overshoot more > >> > - a TCP in slow-start knows that it won't allow the burst to > >> > dissipate anyway > >The end of slow start is an ECN notification or a packet drop. What am >I missing here? A traditional AQM (RED, CoDel, PIE) suppresses=20 any signal (ECN or drop) for another 100ms or so=20 after slow start has pushed the queue over the=20 delay threshold. That's on top of the feedback=20 delay of 1RTT, because it doesn't know this is=20 slow-start, so it waits to see if the queue goes away. The transport knows whether it's in slow-start,=20 so it doesn't need to do any smoothing here - it=20 can drop straight out of slow-start without smoothing. The transport knows when it's in congestion=20 avoidance too, of course, then it can smooth out=20 bursts of ECN by doing its own EWMA over the=20 actual RTT (that it knows properly). Ie the AQM can't be selective about when it=20 smooths bursts, because it doesn't know what=20 phase each transport flow is in, but each transport does and therefore can. > >> A critical point! (It seems obvious to me, but is it obvious to > >> everyone?) > > >> > >> > The solution: make ECN also mean "Immediate Congestion Notification"? > >> > * For ECN-capable packets, shift the job of hiding bursts from= network > >> > to > >> > host: > >> > - the network signals ECN with no smoothing delay > >> > - then the transport can hide bursts of ECN signals from itself > >> > >> But can we get there from here? > >> > >> The node doing the ECN notification _can't_ know how the transport > >> will react; and the transport receiving and ECN notification can't know > >> whether the forwarding node has "smoothed" the signal. (It is truly a > >> shame we haven't left any bits for signals like this!) > > > > > > Well, we do have ECT(1) still only assigned experimentally and never= used, > > which we could decide to use for this immediate ECN. However, first I= want > > to see whether people think it might be feasible to just redefine the > > meaning of CE. > >A lot of the NONCE logic has been discussed in other rfcs. > > > > > Rationale: So few buffers have ECN support turned on anyway that we= should > > be able to redefine ECN so that many more will want to turn it on. > > > > For those AQMs that already support ECN, we believe this retrospective > > change will make them only a little worse than they are already (and the > > operator can update them by simple reconfiguration anyway, and is more > > likely to do so, given these are clearly early-adopter networks). > > > > > >> > - the transport knows > >> > o whether it's TCP or RTP etc, > >> > o whether its in congestion avoidance or slow-start, > >> > o and it knows its RTT, > >> > o so it can know whether to respond immediately or to smooth the > >> > signals, > >> > o and if so, over what time > >> > >> Yes, but it can't know what smoothing may already have been applied. > > > > > > Yes. If this is a problem, we will have to consider using ECT(1) not CE. > > But it's pretty academic when so few buffers support ECN. > > > > The tiny proportion that do support ECN will already smooth by a= 'typical > > RTT' of about 100ms. > > > > If a 20ms RTT flow adds smoothing over its own RTT to this, it will be > > smooth over 120ms. > > The main problem there is not the extra 20ms,=20 > it's the original 100ms, which > > we won't lose unless we make this change somehow. > > > > > >> > - then short RTT flows can smooth the signals with only the delay > >> > of their /own/ RTT > >> > o so they can fill troughs and absorb peaks that longer RTT flows > >> > cannot > >> > - a TCP only needs to smooth the signals if in congestion avoidance > >> > o in slow start, it can respond immediately, thus reducing= overshoot > >> > >> This would, IMHO, improve "slow start". > >> > >> > Incremental Deployment: > >> > * Immediate congestion notification doesn't need new AQM= implementation > >> > - it can use the widely implemented WRED algorithm with an > >> > unexpected configuration > >> > >> Bob is beginning to lose me here. Does he mean that a forwarding= node > >> would apply WRED for both drop and ECN, but with different parameters? > >> > >> > * The network classifies packets for this AQM treatment based on > >> > their ECN-capability > >> > - Without ECN, it smoothes the queue before signalling drops > >> > >> Bob has lost me now -- apparently he doesn't mean different > >> parameters... and I don't recognize this "smoothing" step in WRED. > > > > > > I do mean that a forwarding node would apply=20 > WRED for both drop and ECN, but > > with different parameters. > > > > Each WRED policy-map includes a setting for this smoothing parameter,= which > > Cisco calls the exponential-weighting-constant. Many people don't notice > > it's there and they just leave it at the=20 > default. For instance, Cisco set it > > to > > 2^(-9) ~ 0.002 by default for each of the WRED policy-maps (see > >=20 >= http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fswfq26.html#wp1039= 982). > > > > > >> > - With ECN, it signals immediately, without any smoothing delay > >> > - (as today, the operator can still use WRED with the Diffserv= field > >> > too) > >> > >> (Do we need to confuse this discussion by adding diffserv?) > > > > > > A non-Diffserv network still doesn't need to worry about Diffserv. > > > > I put this in parentheses because, if WRED is=20 > used today, it is usually used > > with Diffserv, and I didn't want anyone to worry that they wouldn't be= able > > to continue to do this (e.g. BT use WRED with Diffserv in enterprise > > networks, as do many other carriers). > >Perhaps we need a taxonomy so we can all talk to areas of the network >we care about? RED as currently defined will not work correctly on >variable rate networks, like wireless... > >I have never thought we'd end up with one aqm or tcp to rule them all.. > >DC: Data Center >WI: Wireless >FL: Fixed Line Again, this immediate ECN stuff is for public=20 Internet (not just data centres). > > > >> > * For TCP apps, the stack will use 'DCTCP' (we've tweaked it), if the > >> > ends negotiate ECN with the accurate feedback capability. > >> > >> Have we settled on "accurate feedback" already? I thought that was > >> still under discussion. (I don't follow exactly what it adds...) > > > > > > See response from Richard Scheffenegger. Essentially the TCPM WG has > > accepted the requirements doc, but not decided between the mechanisms on > > offer. > > > > > >> > * It should 'just work' if an RTP app or a Reno TCP uses ECN. > >> > >> I don't see any way for a Reno transport using ECN to avoid being > >> starved if ECN arrives earlier (without notice). > > > > > > We haven't tested legacy Reno with ECN yet (we figured legacy Reno= without > > ECN is a lot more prevalent, so focused on this first). Nonetheless, > > Reno-ECN is unlikely to starve, because starvation is about long-running > > behaviour, and once a flow has run for more=20 > than a couple of 100ms RTTs, the > > immediate ECN signals should be no different from a smoothed ECN. I= suspect > > Reno-ECN might be worse in its short-term=20 > dynamics. But remember Reno-ECN is > > likely to be a tiny corner-case. > > > > > >> > The request: > >> > * Much more evaluation to do, but first we want to know: > >> > - if the idea works, would the IETF have an appetite for tweaking > >> > the definition of ECN so it is merely equivalent to drop in the long > >> > term, but the dynamics need not be equivalent. > >> > >> There's a good question there; but I don't think we're ready for it. > > > > > > At this stage, even we haven't got many answers. So I'm not asking the= IETF > > to answer the question right now. I'm merely=20 > saying, /if/ our idea works, is > > there at least an /appetite/ in the IETF for=20 > reconsidering the definition of > > ECN? > >I wouldn't mind it, but frankly my own concern was addressing the >security issue, not the current definition. It seems strange that you weren't aware of solutions to this then. > > We wanted to make the IETF aware of this research early, because it= might > > want to at least hold off on any actions that=20 > would otherwise close off this > > option. > > > > > > And if we find that any change is completely=20 > out of the question, we have to > > try a different tack (e.g. ECT(1)). > > > > > >> I'd really like to discuss the dynamics of responding more quickly > >> but perhaps less drastically for almost any real-time flow. > >> > >> But proving "equivalence in the long term" seems too hard. > > > > > > This should be the easy part, because the=20 > longer that conditions are stable, > > a smoothed signal should tend towards an unsmoothed signal, all other > > factors being equal. > > > > Equivalence during dynamics is the hard part, and I'm suggesting we= don't > > sweat too much about that, as long as the performance evaluations are= not > > too far apart. > > > > > >> > Much better than the ECN that didn't get deployed > >> > * This is Explicit and Immediate Congestion Notification (EICN?) > >> > - same wire protocol, much greater benefits > >> > * The advantage of the original ECN (avoiding congestive loss) was > >> > too small to be worth the deployment hassle > >> > >> Actually, I don't agree that was the problem -- instead I believe > >> the code has been deployed but administratively suppressed because > >> the operators don't trust the transports. There _is_ a significant > >> improvement from one-RTT reaction instead of several (to detect a > >> drop), but the whole process is just too complicated, while the > >> opportunity for abuse remains obvious. > > > > > > I agree. That's the 'deployment hassle' side of my sentence - the extra > > trust-enhancing mechanisms that seemed necessary were too much pain for= the > > small gain. > >I > > > > > > >> > * Predictable ultra-low latency without loss too (similar to > >> > DCTCP-ECN) would be worth deploying > >> > >> I'm optimistic that latency will become an easier argument. > >> > >> > * But we all thought DCTCP could only be deployed in isolation (e.g. > >> > data centres) > >> > - we all thought DCTCP traffic would starve alongside today's TCP > >> > traffic > >> > - because in a DCTCP queue, the ECN threshold is lower than you > >> > would trigger drop > >> > - and we thought ECN & drop had to be equivalent. > >I'm looking forward to being convinced otherwise. Yup, I don't want to take up too much of anyone's=20 time with this until we've proved it. But we=20 decided a heads up was important. That's all. Bob > >> (I'm not sure we'll succeed at breaking that "equivalence"...) > >> > >> > * We believe we've found a way to ensure DCTCP-ECN traffic doesn't > >> > starve > >> > - we still make DCTCP-ECN equivalent to drop in the long-run, but > >> > not in its dynamics > >> > >> (I'm still not sure it's worth arguing the "long-run".) > > > > > > I mean competing long-running ECN & non-ECN flows stabilise at= predictable > > rates, rather than one ratchetting itself down to nothing over time > > (starvation). > > > > That's the primary concern of congestion control 'fairness', before= anyone > > starts worrying about what the relative rates are. Given apps get= different > > relative rates with different RTTs, with different size objects or by > > opening multiple flows, we don't need to=20 > sweat so much about precisely equal > > flow rates; but we must sweat about stable convergence. > > > > Results so far show that the proposed idea is at least very robust= against > > starvation. > > > > > > Bob > > > > > >> -- > >> John Leslie > > > > > > ________________________________________________________________ > > Bob Briscoe, BT > > _______________________________________________ > > aqm mailing list > > aqm@ietf.org > > https://www.ietf.org/mailman/listinfo/aqm > > > >-- >Dave T=E4ht > >Fixing bufferbloat with cerowrt:=20 >http://www.teklibre.com/cerowrt/subscribe.html ________________________________________________________________ Bob Briscoe, BT=20 From Ruediger.Geib@telekom.de Mon Oct 28 00:40:24 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D9811E81E8 for ; Mon, 28 Oct 2013 00:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifLoZyimtOdj for ; Mon, 28 Oct 2013 00:40:18 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 1106921F9EAD for ; Mon, 28 Oct 2013 00:40:12 -0700 (PDT) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 28 Oct 2013 08:40:06 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 28 Oct 2013 08:40:06 +0100 From: To: , Date: Mon, 28 Oct 2013 08:40:05 +0100 Thread-Topic: [tsvwg] I-D Action: draft-geib-tsvwg-diffserv-intercon-04.txt Thread-Index: Ac7PgnNHcJ32g/P0RlO/NP3iuHVYFAAeBTdgAO2OQqA= Message-ID: References: <20131018082525.2295.99744.idtracker@ietfa.amsl.com> <526710D1.7050005@gmail.com> <8D3D17ACE214DC429325B2B98F3AE712025DED6E31@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712025DED6E31@MX15A.corp.emc.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-geib-tsvwg-diffserv-intercon-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 07:40:24 -0000 David, Brian, terminology will be changed to "DSCP Aggregation Prefix" in the next versio= n. Thanks and regards, Ruediger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of B= lack, David Sent: Wednesday, October 23, 2013 4:17 PM To: Brian E Carpenter; tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-geib-tsvwg-diffserv-intercon-04.txt Changing Precedence to Aggregation makes sense to me. Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Tuesday, October 22, 2013 7:57 PM > To: tsvwg@ietf.org > Subject: Re: [tsvwg] I-D Action: draft-geib-tsvwg-diffserv-intercon-04.tx= t > > Hi R=FCdiger, > > > DSCP Precedence Prefix The bits 0-2 of the DSCP (marked "x" in this > > generic DSCP field: xxxddd) are called the DSCP Precedence > > Prefix [RFC2474] in the following. By ignoring the value of > > bits 3-6 ( d stands for don' care), a simple aggregation of > > PHBs differed by DSCP is possible in IP and MPLS backbones, > > but also if Ethernet transport is applied. > > Thankyou for providing explicit terminology for this. I am still worried > that by reviving the word "precedence" we would seriously damage outsider= s' > understanding of differentiated services. The specific reason we got rid > of "precedence" and the notion of simple priority (except for implementin= g > the legacy code points) was to underline that precedence doesn't provide > quality of service; if anything, it provides quality of disservice. > > Couldn't you call those three bits "DSCP Aggregation Prefix"? Then they > would refer to 8 traffic classes, and only in a very primitive > implementation would they be mapped to priority levels. > > Brian > From kivinen@iki.fi Mon Oct 28 07:05:26 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF06611E8144; Mon, 28 Oct 2013 07:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+1wIcOtxRKV; Mon, 28 Oct 2013 07:05:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1BDC11E833F; Mon, 28 Oct 2013 07:05:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9SE5Cru002667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Oct 2013 16:05:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9SE5A4g004758; Mon, 28 Oct 2013 16:05:10 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21102.28438.340833.664427@fireball.kivinen.iki.fi> Date: Mon, 28 Oct 2013 16:05:10 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Cc: tsvwg , Joe Touch , "" , "" , "" , Matt Mathis , "" , Valery Smyslov Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 14:05:27 -0000 Yoav Nir writes: > 3. While the TCP stack has access to these ICMP packets and the > PMTU that they convey, a userspace IKE daemon usually doesn't. See > [1] for how people suggest doing it in C#. Actually for example our code tries to get ICMP messages for IKE packets, mostly so that we can make timeout shorter if we start to receive ICMP messages saying the other end is not going to responded. If we get ICMP port unreachable for every single IKE packet we send, there is no point of waiting for 2 minutes and 15 retranmissions to realize that the other end is not responding, 20 seconds and 5 retries might be better... > IKE is supposed to be done in two round-trips. It would be better to > just pick 576 and send way too many IKE fragments then to try PMTU > discovery. Yes. We are talking here about sending one 500-300 byte message from initiator to responder, and getting about same sized message back. After that we will only use few hundred bytes long exchanges. Doing PMTU for sending and receiving one packet is bit overkill. -- kivinen@iki.fi From touch@isi.edu Mon Oct 28 09:22:57 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06F711E8232; Mon, 28 Oct 2013 09:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GHtHf51vZP9; Mon, 28 Oct 2013 09:22:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7E11E8192; Mon, 28 Oct 2013 09:22:52 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9SGLZrk028562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Oct 2013 09:21:44 -0700 (PDT) Message-ID: <526E8F14.7050308@isi.edu> Date: Mon, 28 Oct 2013 09:21:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yoav Nir References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu><14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu><5268060B.4060604@isi.edu><81953CE6126542A8AD40207921B8E018@buildpc><52695365.4070803@isi.edu><526AD233.3090109@isi.edu> <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> In-Reply-To: <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , "" , "" , "" , Matt Mathis , "" , Valery Smyslov Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:22:57 -0000 On 10/27/2013 11:20 PM, Yoav Nir wrote: > I guess the idea is that if the packet is still bigger than the PMTU, > then the IKE host gets back a "fragmentation needed" ICMP, and the IKE > daemon learns of that and resends packets with appropriately small size. > > There are some issues with this: You proceed to describe how PMTUD works, but this is intended (AFAICT) to be more like PLMUTD - which does not rely on ICMPs. Joe From touch@isi.edu Mon Oct 28 09:28:39 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E2521E80D8; Mon, 28 Oct 2013 09:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXAei6pzgyDB; Mon, 28 Oct 2013 09:28:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 93CD121E80C9; Mon, 28 Oct 2013 09:28:32 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9SGPo8c029826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Oct 2013 09:25:59 -0700 (PDT) Message-ID: <526E9013.9020103@isi.edu> Date: Mon, 28 Oct 2013 09:25:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <9535B3BF68684F65992AEF03F3263FEA@buildpc> In-Reply-To: <9535B3BF68684F65992AEF03F3263FEA@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:28:39 -0000 On 10/27/2013 10:41 PM, Valery Smyslov wrote: >>> Always setting DF bit in this case will probably increase the delay >>> before IKE SA is set up (as more probes will need to be done). >> >> Except that if you continue to allow IP fragmentation, you can't claim >> your solution is robust to IP fragment poisoning. > > I think it is. > > Consider the situation when IKE responder is under attack > via IP fragmentation (no matter which - poisoning attack or memory > exhausting attack). In any case responder will not be able to reply. > After some (short) timeout initiator will try to apply IKE Fragmentation. > Then, if those new messages are not fragmented on the path, they > will bypass reassembly code on responder and the attack will > be thwarted. If those messages are fragmented, even with their > smallest allowed size, then it doesn't matter whether DF bit is set or not. > If it is set, fragmenting device will drop messages, if it is not set, > than attack will not be thwarted. Nothing can be done. You're not proposing to use the smallest size, which would be 68 bytes. So by not setting DF, you're enabling a fragmentation attack. If you set DF, a receiver could drop all fragments from addresses it wants to protect against IKE fragment poisoning. Joe From mattmathis@google.com Mon Oct 28 15:22:35 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B075611E82B2 for ; Mon, 28 Oct 2013 15:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkK1ufXygsT9 for ; Mon, 28 Oct 2013 15:22:35 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C1B2B11E8345 for ; Mon, 28 Oct 2013 15:22:30 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tp5so12566435ieb.16 for ; Mon, 28 Oct 2013 15:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LEELEPVdHe9MAVJj8IkJ5cZ7hDWuKIdbeg64dIBHDv8=; b=TEUHFdy52Luns3VBMfV/zVq1VGixeDsTV1/wPvXaNUyi0xdBNVTwkXyw/Ace1Pcxo3 OFyaZj8GNqmpUDbepvQEkdzYrq2X4gW96xfluVAZTbp1EAtsfwzK3psnzlQKFkx5mt+x 433jxsy1ie1kWycWBE3zwz38un7A03H1TuQafXo1exHWqp6bFfgIwdnoPdqn+iuzTHnk Xl8yDCCJEVZC+ZDd/aR/VdKuReIWSZs9ed5SUs9v7vwyY2bSqK9UZo41JRne/hBCdSIm NFkfIXcW8cZ0/+QK1fRgKSD+66FilsQt/IyDy2IeViNfagKwuPEr3iuv2DgqTWeuEUYH zlRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LEELEPVdHe9MAVJj8IkJ5cZ7hDWuKIdbeg64dIBHDv8=; b=VMJUsvo8pJi+Sbq2rXfGloSnfp18ycTqLXFPGpdXR1+AReJtcarnl5N8bJYM9lqyjk +d9H8478oVru9eUvKhJQxWAIl3G4PLkRqXEfIiBGLQExdlkXevAr9jJQ/wYWZrNLMpHd J+S7r5VAt6WCpejfboK12Io11hAaTQjWMdflzYkMR/N4BkqTVZSvrCj8Kfw7k5DQf8A9 butIBSFl8KA+ws90fPCdmFVXy3FSAROx3L/Y547/MMIuiD292QeBMaq0Dq305dtdmiJ0 DvJ2tTlW/yBvgnQQITBY5FTJtIr3GsStD23Y8VbuplohRnvTBjjKv9v6dT9AzKPcA+Nx 3YYA== X-Gm-Message-State: ALoCoQn9aSjbThsI1mEEqgO46RXJ6n4h5cuySyBH6l3htjVwbAw4j+5ZqNcG9ZObKtZwlN/8UMJJI1dPlFnwtuuy/0aN01awzghmV1JLbCNDxhd4rQ28JozmPRwrNilWD9r0bKd06FDEHMbVlYCnQOySwbrIEantSpGoLD/1cWUcIAZ/ztbGaWbb5IZK47rQXd9tWZ9h+09S MIME-Version: 1.0 X-Received: by 10.50.23.16 with SMTP id i16mr10191213igf.50.1382998950018; Mon, 28 Oct 2013 15:22:30 -0700 (PDT) Received: by 10.64.243.66 with HTTP; Mon, 28 Oct 2013 15:22:29 -0700 (PDT) In-Reply-To: References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> Date: Mon, 28 Oct 2013 15:22:29 -0700 Message-ID: From: Matt Mathis To: Valery Smyslov Content-Type: multipart/alternative; boundary=089e0158a9aa24304c04e9d489eb Cc: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, "tsv-dir@ietf.org" Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 22:22:35 -0000 --089e0158a9aa24304c04e9d489eb Content-Type: text/plain; charset=ISO-8859-1 Setting DF is supposed to prevent some midpath IPv4 device from silently "fixing" a MTU problem by doing you a favor that you don't want. IPv4 fragmentation can be used in a mode that mimics IPv6: Only fragment on the originating host, always set DF on on all outbound packets, even if they are already fragmented. Any protocol or application that does not work in this configuration will also fail on IPv6. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Sun, Oct 27, 2013 at 10:50 PM, Valery Smyslov wrote: > ** > Hi Matt, > > the whole idea of the draft is avoiding IP fragmentation for IKE when > it prevents IKE to work. What about DF bit - I don't see how setting it > would help IKE to work. > > Regards, > Valery. > > > ----- Original Message ----- > *From:* Matt Mathis > *To:* Valery Smyslov > *Cc:* tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; > draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org; Joe > Touch > *Sent:* Saturday, October 26, 2013 12:41 AM > *Subject:* Re: [tsvwg] [IPsec] TSVDIR-ish > reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 > > I concur with Joe: once you have enough machinery work well with IPv6 > fragmentation semantics, you should use it for IPv4 too, and > unconditionally set DF. This probably applies to *all* protocols. > > IPv4 reassembly is hopelessly out of scale. IP ID wrap times are likely > to be sub second for any large CGN connecting to any large service..... > They might even be shorter than the queuing times. > > I suspect that if you re-review decade old papers on fragmentation, you > will find some scale assumptions that are no longer correct. In that time > the Internet has moved at least another two orders of magnitude in packet > rates. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat privacy and > security as matters of life and death, because for some users, they are. > > > On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch wrote: > >> >> >> On 10/24/2013 10:45 PM, Valery Smyslov wrote: >> ... >> >>> You're using existing IKE messages *and* existing timeouts to >>>> determine when there is a problem. A separate timer would be useful, >>>> if only to allow you to decouple fragment retransmission from IKE >>>> transaction retries. >>>> >>> >>> No, the timeouts are different. I should have made it more expplicit in >>> the draft. >>> >> >> That'd be useful. >> >> ... >> >>> Always setting DF bit in this case will probably increase the delay >>> before IKE SA is set up (as more probes will need to be done). >>> >> >> Except that if you continue to allow IP fragmentation, you can't claim >> your solution is robust to IP fragment poisoning. >> >> Note, that this approach is in line with advices, given for IKE in the >>>>> paper >>>>> >>>>> C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection >>>>> for UDP-based protocols", ACM Conference on Computer and >>>>> Communications Security, October 2003. >>>>> >>>> >>>> That paper doesn't consider IKE-level fragmentation, which you're >>>> introducing. I agree that DF=0 for IKE without IKE-level fragmentation. >>>> >>> >>> It does, in Section 3.3. >>> >> >> Sorry - I missed that. But that section also gives good reasons why this >> is a bad idea in IKE too. >> >> Joe >> > > --089e0158a9aa24304c04e9d489eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Setting DF is supposed to prevent some midpath IPv4 device= from silently "fixing" a MTU problem by doing you a favor that y= ou don't want.

IPv4 fragmentation can be used in a m= ode that mimics IPv6: Only fragment on the originating host, always set DF = on on all outbound packets, even if they are already fragmented. =A0 =A0 An= y protocol or application that does not work in this configuration will als= o fail on IPv6.

Thanks,
--MM--
The best way to predict the future is to create i= t. =A0- Alan Kay

Privacy matters! =A0We know from recent events that= people are using our services to speak in defiance of unjust governments. = =A0 We treat privacy and security as matters of life and death, because for= some users, they are.


On Sun, Oct 27, 2013 at 10:50 PM, Valery= Smyslov <svanru@gmail.com> wrote:
Hi Matt,
=A0
the whole idea of the draft is avoiding IP fragmentation for=20 IKE when
it prevents IKE to work. What about DF bit=20 - I don't=A0see how setting it
would help IKE to work.
=A0
Regards,
Valery.
=A0
----- Original Message -----
From:=20 Matt=20 Mathis
Sent: Saturday, October 26, 2013 12= :41=20 AM
Subject: Re: [tsvwg] [IPsec] TSVDIR= -ish=20 reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

I concur with Joe: once you have enough machinery work w= ell with=20 IPv6 fragmentation semantics, you should use it for IPv4 too, and=20 unconditionally set DF. =A0 This probably applies to *all* protocols.

IPv4 reassembly is hopelessly out of scale. =A0IP ID wrap times are= =20 likely to be sub second for any large CGN connecting to any large service= .....=20 =A0They might even be shorter than the queuing times.

I suspect that if you re-review decade old papers on fragmentation, = you=20 will find some scale assumptions that are no longer correct. =A0In that= =20 time the Internet has moved at least another two orders of magnitude in p= acket=20 rates.

Thanks,
--MM--
The best way to predict the future is to crea= te=20 it. =A0- Alan Kay

Privacy matters! =A0We know from recent events= =20 that people are using our services to speak in defiance of unjust governm= ents.=20 =A0 We treat privacy and security as matters of life and death, because f= or=20 some users, they are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch <touch= @isi.edu> wrote:


On 10/24/2013 10:45 PM, Val= ery Smyslov=20 wrote:
...
You're using existing IKE m= essages *and* existing=20 timeouts to
determine when there is a problem. A separate timer = would=20 be useful,
if only to allow you to decouple fragment retransmiss= ion=20 from IKE
transaction retries.

No, the= =20 timeouts are different. I should have made it more expplicit in
th= e=20 draft.

That'd be useful.

...
Always setting DF bit in this cas= e will probably=20 increase the delay
before IKE SA is set up (as more probes will ne= ed to=20 be done).

Except that if you continue to allow IP= =20 fragmentation, you can't claim your solution is robust to IP fragme= nt=20 poisoning.

Note, that this approach is i= n line with advices,=20 given for IKE in the
paper

C. Kaufman, R. Perlman, and = B.=20 Sommerfeld, "DoS protection
=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 for UDP-based protocols", ACM Conference on Computer= =20 and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Communications=20 Security, October 2003.

That paper doesn'= t consider=20 IKE-level fragmentation, which you're
introducing. I agree t= hat DF=3D0=20 for IKE without IKE-level fragmentation.

= It=20 does, in Section 3.3.

Sorry - I missed that. But = that=20 section also gives good reasons why this is a bad idea in IKE too.

Joe

--089e0158a9aa24304c04e9d489eb-- From ietf-secretariat-reply@ietf.org Thu Oct 24 08:25:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607F711E81C3 for ; Thu, 24 Oct 2013 08:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jI8r+O0W1-zt for ; Thu, 24 Oct 2013 08:25:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D123011E829B for ; Thu, 24 Oct 2013 08:25:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131024152537.2432.8314.idtracker@ietfa.amsl.com> Date: Thu, 24 Oct 2013 08:25:37 -0700 From: IETF Secretariat X-Mailman-Approved-At: Tue, 29 Oct 2013 05:02:00 -0700 Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 15:25:42 -0000 Changed milestone "Submit 'SCTP SACK Immediately' to IESG for consideration as a Proposed Standard RFC", resolved as "Done". URL: http://datatracker.ietf.org/wg/tsvwg/charter/ From yaronf.ietf@gmail.com Fri Oct 25 12:36:08 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00F711E81CF; Fri, 25 Oct 2013 12:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+XWxXj5hvcT; Fri, 25 Oct 2013 12:36:07 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BE10C11E81CB; Fri, 25 Oct 2013 12:35:52 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so4215699wgh.13 for ; Fri, 25 Oct 2013 12:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MTY8VntCg1ohpihmWatF9v6ad5kucyvn9Ml0fLu+wK8=; b=Dkj7t+K9kI9zzy2rx9k8UDbLOPpunGz/7/94/m6eABBaz9D2mJaRRL4M9Dsxarlc6n 7OvNIw6v7x5NkhZamMrOezOp9TSqd4KCkzRG4s/vzkGZ/Ut+vZdQ3qUNNrv2cypUjIWW X9OlIVau+nn3EUxpmXks9tZjEyJ69pcuN7gk1o4codGYV09RNkibu7TcR80Rkm/jmlTC 6LisEF0AgLCm3AWBbF3EWX2jyVbDQZ+MHoEeQ09eBJOWTWvalxrkWgVBzuBbkqiMDPRI gcR0GUBgb1I8N2uqvLt/uZDYJJWk/ZlxDY4LW4+t+ooeztz13lmi/HFVsJlx708dq+iR oAqQ== X-Received: by 10.194.109.68 with SMTP id hq4mr8839108wjb.12.1382729749040; Fri, 25 Oct 2013 12:35:49 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id i8sm9231920wiy.6.2013.10.25.12.35.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 12:35:48 -0700 (PDT) Message-ID: <526AC812.7070903@gmail.com> Date: Fri, 25 Oct 2013 22:35:46 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Paul Wouters , Valery Smyslov References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Oct 2013 05:02:00 -0700 Cc: "ipsec@ietf.org WG" , tsv-ads@tools.ietf.org, tsvwg Subject: Re: [tsvwg] [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:36:08 -0000 Hi Paul, Sorry for the late reply. You seem to assume that SPIs are random. This is not mandated by IKEv2 and in practice it is usually, but not always, the case. See http://www.ietf.org/mail-archive/web/ipsec/current/msg06563.html Thanks, Yaron On 2013-10-22 18:35, Paul Wouters wrote: > On Tue, 22 Oct 2013, Valery Smyslov wrote: > >>> attacks (e.g., overloading the receiver with false fragments). >> >> This attack is always possible both with and without fragmentation >> (just overloading with false full messages) and IKE is designed to >> withstand it. > > Partially. For unfragmented IKE, the cookies/SPI mitigate this if > you give preference to IKE messages further in the processing queue. > With this draft, I'm forced to do more crypto on IKE packets before I > can decide if these need prioritization or not (with the exception of > the first packet, which cannot get fragmented anyway) > >> Handling fragmentation in IKE doesn't make it more vulnerable to this >> attack. > > Handling encrypted fragments does, because you will spend more time > doing the crypto. Although this still happens after the cookie/spi > verification. You are doing an additional round of crypto on each fragment > in addition to the regular IKE crypto you need to perform on the assembled > packet. Fragments could be made artificially long and the IKE packet > artificial big, resulting in much more crypto. Now I think this might > not matter much, because the attacker needs to be local and they will > only be local to a remote endpoint which has enough CPU, not the ipsec > core gateway that actually might run out of CPU power when under attack. > >> On the other hand, handling fragmentation outside IKE (on IP level) >> or using unauthenticated fragments in IKE, makes it susceptible to an >> attack, >> described in the rationale, i.e. when attacker spending virtually zero >> resources >> can stop IKE communication by infrequently injecting bad fragments, >> which results in "poisoning" of reassembling queue. > > But the attack is theoretical and of no practical value. > > 1) on-path attacker (remote) > > They can just DOS you regardless by withholding packets. > > 2) off-path attacker (remote) > > These attackers don't know the cookies/spi's so they can't really sent > a forged fragment you would use for assembly - protected with crypto or > not. It is also impossible for them to time their attack so that one of > their fragments intersect with one of your fragments so they would need > to start sending fragments before the endpoint does but using mostly > wrong cookies/spis and would swamp an endpoint with easilly detectable > forged packets. > > 3) shared medium like wifi hotspot (local) > > These are the only attackers with enough knowledge to sent sufficiently > advanced bad fragments interfering with incoming fragments. They can > already do all the damage they want without resorting to IKE fragment > spoofing. They can arp spoof the gateway, sent a Wifi de-association > request, sent enough garbage to fill the air waves, and interfere with > the IKE in such a way that you think the remote peer does not support > fragmentation at all. So this draft protects against a local attacker > that wants to masquerade as a network failure and only prevent you from > doing IKE, hoping you will fall back to plaintext traffic. Software > could notify the user that they seem to be under attack, which IMHO > would be more valuable to the user than quiet resilience against the > attack. > >> Using authenticated fragments prevents this kind of attack. > > Yes, it prevents one of the low hanging fruits. Which I don't think is > worth the complexity of this draft compared to the existing > fragmentation code out in the wild. > >> But using IKE fragmentation in this case might eliminate this >> vulnerability. > > At the price of adding more complexity to IKE. With the attacker not > stopped from their goal. > >>> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC >>> 4821), and should be described as such. >> >> IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based >> and RFC4821 has many restrictions when used with connectionless >> datagram protocols, some of which are often difficult to satisfy in >> environments, >> where IKE is used. Second, the goal of PLMTUD is to find _maximum_ >> MTU size that is not fragmented by IP, in other words, to maximize >> throughput. For IKE the goal of PMTUD is to find _any_reasonable_ >> MTU size that won't be fragmented by IP. Throughput is not important. >> Third, PMTU discovery in the draft is completely optional and one may >> use any other mechanisms (including PLMTUD, if it is available) >> to obtain MTU information. > > I agree. There is going to be like 2 to 4 fragments. Size does not > matter. It's better to cut down on latency/RTT by using an MTU size > that is for sure to work on the first go. > > But that's also why this complexity is not worth it. Fragmentation does > only mean going from 1 IKE packet to 2-4 IKE packets. The timeframe > to mess with these are in the 5ms range. If an attacker has that > accuracy against you, you've lost already regardless. I doubt the > attacker can even pull it off on wifi. > > The original IKE fragmentation is really nice and simple. Copy part of > the original IKE header, add a single payload with fragment payload > type and fragment number/max, sent fragments in a burst. > > This draft looks like it is fixing a security issue, while it really > should be just about sending smaller packets as similar as possible > to the original single packet. Messing with one IKE packet versus 2-4 > IKE packets is not a real problem that I think needs fixing. > > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Sun Oct 27 23:21:20 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D5321E8085; Sun, 27 Oct 2013 23:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hV9ESyeXmWz; Sun, 27 Oct 2013 23:21:12 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1871311E8331; Sun, 27 Oct 2013 23:21:07 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9S6Ksqj011022; Mon, 28 Oct 2013 08:20:54 +0200 X-CheckPoint: {526E0164-5-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 28 Oct 2013 08:20:35 +0200 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 Thread-Index: AQHO06GjEWbxzVDlyUWyTasGrxZ2zpoJgu+A Date: Mon, 28 Oct 2013 06:20:30 +0000 Message-ID: <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu><14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu><5268060B.4060604@isi.edu><81953CE6126542A8AD40207921B8E018@buildpc><52695365.4070803@isi.edu><526AD233.3090109@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.225] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_0E72C76582CF4A2CBE6A31735954A9BBcheckpointcom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 29 Oct 2013 05:02:00 -0700 Cc: tsvwg , Joe Touch , "" , "" , "" , Matt Mathis , "" Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 06:21:20 -0000 --_000_0E72C76582CF4A2CBE6A31735954A9BBcheckpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I guess the idea is that if the packet is still bigger than the PMTU, then = the IKE host gets back a "fragmentation needed" ICMP, and the IKE daemon le= arns of that and resends packets with appropriately small size. There are some issues with this: 1. It requires yet another retransmission 2. There's a lot of things on the IPv4 Internet that drop ICMP messages. I= Pv6 simply doesn't work without them, but IPv4 usually manages. 3. While the TCP stack has access to these ICMP packets and the PMTU that = they convey, a userspace IKE daemon usually doesn't. See [1] for how people= suggest doing it in C#. IKE is supposed to be done in two round-trips. It would be better to just p= ick 576 and send way too many IKE fragments then to try PMTU discovery. Yoav [1] http://stackoverflow.com/questions/4142080/path-mtu-discovery-in-c-shar= p On Oct 28, 2013, at 7:50 AM, Valery Smyslov > wrote: Hi Matt, the whole idea of the draft is avoiding IP fragmentation for IKE when it prevents IKE to work. What about DF bit - I don't see how setting it would help IKE to work. Regards, Valery. ----- Original Message ----- From: Matt Mathis To: Valery Smyslov Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; draft-ietf-ipsecme-= ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org ; Joe Tou= ch Sent: Saturday, October 26, 2013 12:41 AM Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fr= agmentation-04 I concur with Joe: once you have enough machinery work well with IPv6 fragm= entation semantics, you should use it for IPv4 too, and unconditionally set= DF. This probably applies to *all* protocols. IPv4 reassembly is hopelessly out of scale. IP ID wrap times are likely to= be sub second for any large CGN connecting to any large service..... They= might even be shorter than the queuing times. I suspect that if you re-review decade old papers on fragmentation, you wil= l find some scale assumptions that are no longer correct. In that time the= Internet has moved at least another two orders of magnitude in packet rate= s. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our serv= ices to speak in defiance of unjust governments. We treat privacy and sec= urity as matters of life and death, because for some users, they are. On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch > wrote: On 10/24/2013 10:45 PM, Valery Smyslov wrote: ... You're using existing IKE messages *and* existing timeouts to determine when there is a problem. A separate timer would be useful, if only to allow you to decouple fragment retransmission from IKE transaction retries. No, the timeouts are different. I should have made it more expplicit in the draft. That'd be useful. ... Always setting DF bit in this case will probably increase the delay before IKE SA is set up (as more probes will need to be done). Except that if you continue to allow IP fragmentation, you can't claim your= solution is robust to IP fragment poisoning. Note, that this approach is in line with advices, given for IKE in the paper C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003. That paper doesn't consider IKE-level fragmentation, which you're introducing. I agree that DF=3D0 for IKE without IKE-level fragmentation. It does, in Section 3.3. Sorry - I missed that. But that section also gives good reasons why this is= a bad idea in IKE too. Joe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_0E72C76582CF4A2CBE6A31735954A9BBcheckpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0F175F27AD02A84080DA1735FD1304D7@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable I guess the idea is that if the packet is still bigger than the PMTU, then = the IKE host gets back a "fragmentation needed" ICMP, and the IKE= daemon learns of that and resends packets with appropriately small size.

There are some issues with this:
 1. It requires yet another retransmission
 2. There's a lot of things on the IPv4 Internet that drop ICMP m= essages. IPv6 simply doesn't work without them, but IPv4 usually manages.
 3. While the TCP stack has access to these ICMP packets and the = PMTU that they convey, a userspace IKE daemon usually doesn't. See [1] for = how people suggest doing it in C#.

IKE is supposed to be done in two round-trips. It would be better to j= ust pick 576 and send way too many IKE fragments then to try PMTU discovery= .

Yoav


On Oct 28, 2013, at 7:50 AM, Valery Smyslov <svanru@gmail.com> wrote:

Hi Matt,
 
the whole idea of the draft is avoiding IP fragmentat= ion for IKE when
it prevents IKE to work. What about DF bit - I don't&n= bsp;see how setting it
would help IKE to work.
 
Regards,
Valery.
 
----- Original Message -----
From: Matt Mathis
Sent: Saturday, Oc= tober 26, 2013 12:41 AM
Subject: Re: [tsvw= g] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

I concur with Joe: once you have enough machinery work wel= l with IPv6 fragmentation semantics, you should use it for IPv4 too, and un= conditionally set DF.   This probably applies to *all* protocols.

IPv4 reassembly is hopelessly out of scale.  IP ID wrap times are= likely to be sub second for any large CGN connecting to any large service.= ....  They might even be shorter than the queuing times.

I suspect that if you re-review decade old papers on fragmentation, yo= u will find some scale assumptions that are no longer correct.  In tha= t time the Internet has moved at least another two orders of magnitude in p= acket rates.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our= services to speak in defiance of unjust governments.   We treat priva= cy and security as matters of life and death, because for some users, they = are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch <touch@isi.edu> wrote:


On 10/24/2013 10:45 PM, Valery Smyslov wrote:
...
You're using existing IKE messages *and* existing timeouts to
determine when there is a problem. A separate timer would be useful,
if only to allow you to decouple fragment retransmission from IKE
transaction retries.

No, the timeouts are different. I should have made it more expplicit in
the draft.

That'd be useful.

...
Always setting DF bit in this case will probably increase the delay
before IKE SA is set up (as more probes will need to be done).

Except that if you continue to allow IP fragmentation, you can't claim your= solution is robust to IP fragment poisoning.

Note, that this approach is in line with advices, given for IKE in the
paper

C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection
              for UDP-based protocols&qu= ot;, ACM Conference on Computer and
              Communications Security, O= ctober 2003.

That paper doesn't consider IKE-level fragmentation, which you're
introducing. I agree that DF=3D0 for IKE without IKE-level fragmentation.

It does, in Section 3.3.

Sorry - I missed that. But that section also gives good reasons why this is= a bad idea in IKE too.

Joe

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec

--_000_0E72C76582CF4A2CBE6A31735954A9BBcheckpointcom_-- From ynir@checkpoint.com Mon Oct 28 07:28:17 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1AD11E8306; Mon, 28 Oct 2013 07:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+j7DBdQw35K; Mon, 28 Oct 2013 07:28:11 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9008411E8276; Mon, 28 Oct 2013 07:28:06 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9SERvQG011748; Mon, 28 Oct 2013 16:27:57 +0200 X-CheckPoint: {526E7385-B-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 28 Oct 2013 16:27:57 +0200 From: Yoav Nir To: Tero Kivinen Thread-Topic: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 Thread-Index: AQHO0+bd0LfaEbGSDEaJqrSL9NUM7ZoKKuuA Date: Mon, 28 Oct 2013 14:27:55 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772121AB0070@IL-EX10.ad.checkpoint.com> References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> <21102.28438.340833.664427@fireball.kivinen.iki.fi> In-Reply-To: <21102.28438.340833.664427@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.27] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 29 Oct 2013 05:02:00 -0700 Cc: tsvwg , Joe Touch , "" , "" , "" , Matt Mathis , "" , Valery Smyslov Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 14:28:17 -0000 OK, you convinced me. 576 is the right value to recommend for initiator. No= t sure if for responder it's also preferable to use 576, or to go with the = idea in 2.5.1 of using the fragment size from the request. Yoav -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Monday, October 28, 2013 4:05 PM To: Yoav Nir Cc: Valery Smyslov; tsvwg; Joe Touch; ; ; ; Matt Mathis= ; Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fr= agmentation-04 Yoav Nir writes: > 3. While the TCP stack has access to these ICMP packets and the PMTU=20 > that they convey, a userspace IKE daemon usually doesn't. See [1] for=20 > how people suggest doing it in C#. Actually for example our code tries to get ICMP messages for IKE packets, m= ostly so that we can make timeout shorter if we start to receive ICMP messa= ges saying the other end is not going to responded. If we get ICMP port unreachable for every single IKE packet we send, there = is no point of waiting for 2 minutes and 15 retranmissions to realize that = the other end is not responding, 20 seconds and 5 retries might be better..= . > IKE is supposed to be done in two round-trips. It would be better to=20 > just pick 576 and send way too many IKE fragments then to try PMTU=20 > discovery. Yes. We are talking here about sending one 500-300 byte message from initia= tor to responder, and getting about same sized message back. After that we will only use few hundred bytes long exchanges. Doing PMTU for sending and receiving one packet is bit overkill. -- kivinen@iki.fi Email secured by Check Point From svanru@gmail.com Thu Oct 24 22:45:47 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041C011E813D; Thu, 24 Oct 2013 22:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pp-WuY0j+KC; Thu, 24 Oct 2013 22:45:46 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 048F411E82AD; Thu, 24 Oct 2013 22:45:39 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so349219lbj.17 for ; Thu, 24 Oct 2013 22:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=817cBuN6nNYLL1BL4q2sNN2jfobyYIqeeVMVEEXLjtY=; b=c7krcE4FnkSskTnXKHbZCaUY/eddVmZLkslt6/39XG7/e6GZ4UyM9uatvqgoqSexPw jH8StCvHAX6jiF7Y/nKOsbvL4nGIG4NzSuF8gyENFDmyZGfo9aUYvTVFvN/9Yc1+rFye lx6kDwzvyow+OaJWXRwqJ0n/zsEDIjVTWFMi+dXYXx5LhgtP8rLjquAjNNlrnHdy5gRB rG9DiXkImplJK+cWpAEnz96H3fLM7JfXHs/+tdW5FUoQIMmXBGse9pvnrtOV+MZyaAS3 mOYj5yewT0dQ68+MPNa7VT6GZ3EXj12iWBLSCHfawFIprow/25zpJBgawz3EpIJch3qE nnhQ== X-Received: by 10.112.89.100 with SMTP id bn4mr1122815lbb.16.1382679938894; Thu, 24 Oct 2013 22:45:38 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vk8sm1330016lbb.0.2013.10.24.22.45.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Oct 2013 22:45:38 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Joe Touch" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> Date: Fri, 25 Oct 2013 09:45:48 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Tue, 29 Oct 2013 05:02:06 -0700 Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 05:45:47 -0000 >> That's true. I don't see any requirements in section 10.4. that the >> probes >> must be distinct. Request/reply nature of IKE's messages make them >> well suitable for probes and I see no need here to introduce >> separate mechanism, adding complexity, consuming bandwith and adding >> delay. >> Moreover, section 10.4 explicitely allows using application data for >> probes. > > Yes, but there are two components: > - the probes > - the timeouts > > You're using existing IKE messages *and* existing timeouts to determine > when there is a problem. A separate timer would be useful, if only to > allow you to decouple fragment retransmission from IKE transaction > retries. No, the timeouts are different. I should have made it more expplicit in the draft. When doing PMTU discovery host needs to try several MTU sizes before considering peer to be dead, so exchange timeout must be greater then the sum of all probes timeouts. Probe timeout should be relatively short, just less then 10 seconds before going to next size, while the whole exchange timeout is pretty long, about one minute or more. >>> From Section 9: You don't talk about trying to make sure that IPv4 DF >>> is set, as per Section 9, which means that even the conservative >>> values you pick might continue to generate fragments downstream. >> >> With all due respect, I have to disagree that setting DF bit is needed >> in case of IKE. >> With IKE the goal is not to make sure that _no_ IP fragmentation takes >> place >> on the path, but to make sure that IP fragmentation issues, if any, >> do not prevent IKE communications. So, IP fragmentation is present on >> the path, >> but it doesn't bother us - let it be. > > Agreed. But that's the case when IKE works with whatever message size you > start with. > >> If it doesn't allow IKE to work >> (either by dropping IP fragments or by attacking destination host with >> bogus fragments) - we will try to avoid it. So, in your example, even if >> IP fragments are generated downstream, but those fragments are passed - >> let them be. > > Your mechanism kicks in (presumably) when IKE fails, and then you retry > with application-layer fragments. App-layer fragments are useless if the > network level then fragments the messages. That's why you should set DF=1. Again, there's no need for IKE to absolutely disallow IP fragmentation unless it prevents IKE to communicate. If we have two routers down the path, first fragmenting IP packets into size S1 and the second fragmenting them into size S2, so that S2 < S1, and some device between them that drops IP fragments, then it is enough for IKE to make so that application fragments will have size < S1, but probably > S2. Then we will avoid first fragmentation, but will still allow second one, as it doesn't bother us. In this case application fragments are useful, even with the presence of IP fragmentation. Always setting DF bit in this case will probably increase the delay before IKE SA is set up (as more probes will need to be done). >> Note, that this approach is in line with advices, given for IKE in the >> paper >> >> C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection >> for UDP-based protocols", ACM Conference on Computer and >> Communications Security, October 2003. > > That paper doesn't consider IKE-level fragmentation, which you're > introducing. I agree that DF=0 for IKE without IKE-level fragmentation. It does, in Section 3.3. >> that is reffered by RFC5996 as recommendations to protect against IP >> fragmentation issues. Section 3.3 of this paper discusses the ways PMTUD >> should be done in IKE and finds it more advantageous not to set DF bit. > > That too refers to IKE without IKE-level fragmentation (see Sec 2). Again, > once you introduce fragmentation at the IKE-level to avoid IP > fragmentation, it makes no sense to continue to allow it at the IP level. Please, see above. > Joe Regards, Valery. From svanru@gmail.com Sun Oct 27 22:41:58 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D5A11E8100; Sun, 27 Oct 2013 22:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuIYQ6Vt3clu; Sun, 27 Oct 2013 22:41:55 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id B045711E810D; Sun, 27 Oct 2013 22:41:53 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id w6so2436337lbh.38 for ; Sun, 27 Oct 2013 22:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=7gB5O9o3GzZGGi1FojL3ZDChwj7y69b/7Lj9D2cACxs=; b=aeDUrKmAxJVo9KnZcF8HiHbrBH1/03nV8iVv+zdv0ZmHU9IRz7ppdNEBlUryrmXmsP CDPrBgM5oqVJgHsVcmVTfFPoxbVWk13k6CMDHqAR2EXfBt1eiMtG22ihmEYNflc+ZNOy XJFNsG/3SOcJsYoB0DBnugJzxNqu0fu7A3VLKs/jnP2AsYfCFNn0/ycOnVwq+EMmtVUx kgJl8T5E27GboLfpH+900BH/4AzzxvJOoCdW9Nm7zpk92rheGhNSEr/WS7ud6i26ZU/v tCRQ4p82BEKcFZq6gbZnCnQGS6xr7GKHGCbVtci0Bw5PpxtxMBryRTaV3yX4v8xBnnHc 8AQg== X-Received: by 10.112.132.70 with SMTP id os6mr267776lbb.38.1382938912619; Sun, 27 Oct 2013 22:41:52 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id oc1sm11790715lbb.3.2013.10.27.22.41.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Oct 2013 22:41:51 -0700 (PDT) Message-ID: <9535B3BF68684F65992AEF03F3263FEA@buildpc> From: "Valery Smyslov" To: "Joe Touch" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> Date: Mon, 28 Oct 2013 09:41:39 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Tue, 29 Oct 2013 05:02:06 -0700 Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 05:41:58 -0000 >> Always setting DF bit in this case will probably increase the delay >> before IKE SA is set up (as more probes will need to be done). > > Except that if you continue to allow IP fragmentation, you can't claim > your solution is robust to IP fragment poisoning. I think it is. Consider the situation when IKE responder is under attack via IP fragmentation (no matter which - poisoning attack or memory exhausting attack). In any case responder will not be able to reply. After some (short) timeout initiator will try to apply IKE Fragmentation. Then, if those new messages are not fragmented on the path, they will bypass reassembly code on responder and the attack will be thwarted. If those messages are fragmented, even with their smallest allowed size, then it doesn't matter whether DF bit is set or not. If it is set, fragmenting device will drop messages, if it is not set, than attack will not be thwarted. Nothing can be done. Resume: setting DF bit in situation when even the smallest IKE Fragment messages are still fragmented by IP will definitely prevent IKE to work. Unsetting it will leave a chance (as with any DoS attack). >> It does, in Section 3.3. > > Sorry - I missed that. But that section also gives good reasons why this > is a bad idea in IKE too. It lists some drawbacks: added complexity and lack of individual ACKs. They were discussed by WG and found acceptable. It suggests using TCP instead. That was considered by WG, but rejected due to numerous issues. Valery. From svanru@gmail.com Sun Oct 27 22:50:59 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E813B11E80F5; Sun, 27 Oct 2013 22:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHGmxccldPoe; Sun, 27 Oct 2013 22:50:59 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 48B0B11E8333; Sun, 27 Oct 2013 22:50:56 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id eo20so4748504lab.40 for ; Sun, 27 Oct 2013 22:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=/9iLgF5L18FlRoA8KWUZ/I81cN7sXQIb+d6pkVi9a4g=; b=pUzyjKRcCRhy9ALIsPt2sdXN2FAk59IuLs2o6TveysLsWyAnwe++M7caremg1d580B Y0O2G+WbQMyW9vleKiV0On6VVaEDerJE+fM7ZI8DNmUEa7hKf/6OVTpBJmCYt3jrHcDz po/g6izb2JvlATxVdVLJTwATsOoV/ZaBL+oy07BLDY0z6MMbghIcSuVQzzKLGgWBCLew P1AwIpGDNSA3YqOkomOnCJ2k4bUEcLVVwSuRon7zA6vasHHWch3sCra2SJJTPoxQBShR Cm/eFkAQf1zfO8nSPIaFdw/zBPDe5W2zbJLs8y6N/UV7N91p6ZbhHs77olmAOmz365te Kjkg== X-Received: by 10.112.13.72 with SMTP id f8mr122749lbc.40.1382939455200; Sun, 27 Oct 2013 22:50:55 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vx8sm11800471lbb.8.2013.10.27.22.50.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Oct 2013 22:50:54 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Matt Mathis" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu><14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu><5268060B.4060604@isi.edu><81953CE6126542A8AD40207921B8E018@buildpc><52695365.4070803@isi.edu><526AD233.3090109@isi.edu> Date: Mon, 28 Oct 2013 09:50:42 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0467_01CED3C3.2A8ED410" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Tue, 29 Oct 2013 05:02:06 -0700 Cc: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 05:51:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0467_01CED3C3.2A8ED410 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Matt, the whole idea of the draft is avoiding IP fragmentation for IKE when it prevents IKE to work. What about DF bit - I don't see how setting it=20 would help IKE to work. Regards, Valery. ----- Original Message -----=20 From: Matt Mathis=20 To: Valery Smyslov=20 Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; = draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org = ; Joe Touch=20 Sent: Saturday, October 26, 2013 12:41 AM Subject: Re: [tsvwg] [IPsec] TSVDIR-ish = reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 I concur with Joe: once you have enough machinery work well with IPv6 = fragmentation semantics, you should use it for IPv4 too, and = unconditionally set DF. This probably applies to *all* protocols. IPv4 reassembly is hopelessly out of scale. IP ID wrap times are = likely to be sub second for any large CGN connecting to any large = service..... They might even be shorter than the queuing times. I suspect that if you re-review decade old papers on fragmentation, = you will find some scale assumptions that are no longer correct. In = that time the Internet has moved at least another two orders of = magnitude in packet rates. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our = services to speak in defiance of unjust governments. We treat privacy = and security as matters of life and death, because for some users, they = are. On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch wrote: On 10/24/2013 10:45 PM, Valery Smyslov wrote: ... You're using existing IKE messages *and* existing timeouts to determine when there is a problem. A separate timer would be = useful, if only to allow you to decouple fragment retransmission from = IKE transaction retries. No, the timeouts are different. I should have made it more = expplicit in the draft. That'd be useful. ... Always setting DF bit in this case will probably increase the = delay before IKE SA is set up (as more probes will need to be done). Except that if you continue to allow IP fragmentation, you can't = claim your solution is robust to IP fragment poisoning. Note, that this approach is in line with advices, given for = IKE in the paper C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on = Computer and Communications Security, October 2003. That paper doesn't consider IKE-level fragmentation, which = you're introducing. I agree that DF=3D0 for IKE without IKE-level = fragmentation. It does, in Section 3.3. Sorry - I missed that. But that section also gives good reasons why = this is a bad idea in IKE too. Joe ------=_NextPart_000_0467_01CED3C3.2A8ED410 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Matt,
 
the whole idea of the draft is avoiding IP = fragmentation for=20 IKE when
it prevents IKE to work. What = about DF bit=20 - I don't see how setting it
would help IKE to work.
 
Regards,
Valery.
 
----- Original Message -----
From:=20 Matt=20 Mathis
Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; dra= ft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org=20 ; tsv-dir@ietf.org ; Joe Touch
Sent: Saturday, October 26, = 2013 12:41=20 AM
Subject: Re: [tsvwg] [IPsec] = TSVDIR-ish=20 reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

I concur with Joe: once you have enough machinery work = well with=20 IPv6 fragmentation semantics, you should use it for IPv4 too, and=20 unconditionally set DF.   This probably applies to *all* = protocols.

IPv4 reassembly is hopelessly out of scale.  IP ID wrap = times are=20 likely to be sub second for any large CGN connecting to any large = service.....=20  They might even be shorter than the queuing times.

I suspect that if you re-review decade old papers on = fragmentation, you=20 will find some scale assumptions that are no longer correct.  In = that=20 time the Internet has moved at least another two orders of magnitude = in packet=20 rates.

Thanks,
--MM--
The best way to predict the future is to = create=20 it.  - Alan Kay

Privacy matters!  We know from recent = events=20 that people are using our services to speak in defiance of unjust = governments.=20   We treat privacy and security as matters of life and death, = because for=20 some users, they are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch = <touch@isi.edu> wrote:


On 10/24/2013 10:45 PM, Valery Smyslov=20 wrote:
...
You're using existing IKE messages *and* = existing=20 timeouts to
determine when there is a problem. A separate = timer would=20 be useful,
if only to allow you to decouple fragment = retransmission=20 from IKE
transaction retries.

No, = the=20 timeouts are different. I should have made it more expplicit = in
the=20 draft.

That'd be useful.

...
Always setting DF bit in this case will probably = increase the delay
before IKE SA is set up (as more probes will = need to=20 be done).

Except that if you continue to allow = IP=20 fragmentation, you can't claim your solution is robust to IP = fragment=20 poisoning.

Note, that this approach is in line with = advices,=20 given for IKE in the
paper

C. Kaufman, R. Perlman, = and B.=20 Sommerfeld, "DoS protection
        =  =20     for UDP-based protocols", ACM Conference on = Computer=20 and
              = Communications=20 Security, October 2003.

That paper doesn't = consider=20 IKE-level fragmentation, which you're
introducing. I agree = that DF=3D0=20 for IKE without IKE-level = fragmentation.

It=20 does, in Section 3.3.

Sorry - I missed that. = But that=20 section also gives good reasons why this is a bad idea in IKE = too.

Joe

------=_NextPart_000_0467_01CED3C3.2A8ED410-- From svanru@gmail.com Mon Oct 28 22:53:37 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83BF11E80FC; Mon, 28 Oct 2013 22:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mxXp+gdNYfz; Mon, 28 Oct 2013 22:53:37 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7E11E810D; Mon, 28 Oct 2013 22:53:36 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id q8so3641864lbi.33 for ; Mon, 28 Oct 2013 22:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=nLJB3N1ji/Duiz++eMvCOaUKlBAXiWgsWyYKrR2QvHo=; b=cbQYDzwTWDoVWTATXw6XcqCoVZx1wcuUoty4jYAnNr+4/FAIZ2Z9jIPBpTp7Pipaii CNxgUo8P/vZVpMnRZqPUw2EUqEUs4CGg6PkOb0SDNhXfAaQNCxkKSJDq27YXZRSiQKBQ UIha9QwAX0/VOrqAGtOrjI1aOw5H6OikznNjIEB+3yqVlG8uf2l+dtlxTxAYEFVO/nGi SqcaRIMOyaSEC5Pxb4Tj6pu+SdhLLwZOwk+8UP4pMc+cPHEAMG8j4wV28Vs0sF1aiFwc YMnOAyegl8clv3mBpAZs9+uyEoBZEAm4MaJHIJSbQ8p1AeohZPObWvE8DPjId/eUsgv/ IVjQ== X-Received: by 10.152.36.170 with SMTP id r10mr530132laj.48.1383026015499; Mon, 28 Oct 2013 22:53:35 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id m13sm15332337lbo.11.2013.10.28.22.53.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 28 Oct 2013 22:53:34 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Joe Touch" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <9535B3BF68684F65992AEF03F3263FEA@buildpc> <526E9013.9020103@isi.edu> Date: Tue, 29 Oct 2013 09:53:31 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Tue, 29 Oct 2013 05:02:07 -0700 Cc: tsvwg , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 05:53:38 -0000 >> Consider the situation when IKE responder is under attack >> via IP fragmentation (no matter which - poisoning attack or memory >> exhausting attack). In any case responder will not be able to reply. >> After some (short) timeout initiator will try to apply IKE Fragmentation. >> Then, if those new messages are not fragmented on the path, they >> will bypass reassembly code on responder and the attack will >> be thwarted. If those messages are fragmented, even with their >> smallest allowed size, then it doesn't matter whether DF bit is set or >> not. >> If it is set, fragmenting device will drop messages, if it is not set, >> than attack will not be thwarted. Nothing can be done. > > You're not proposing to use the smallest size, which would be 68 bytes. No, as it is not possible with this solution. Depending on algorithms involved the smallest IP packet containing IKE message is about 100 bytes, and it is almost useless as in this case it contains only a few bytes of useful data. The minimum IP packet size still useful would be about 256 bytes. > So by not setting DF, you're enabling a fragmentation attack. If you set > DF, a receiver could drop all fragments from addresses it wants to protect > against IKE fragment poisoning. Yes. But if even the smallest IKE messages are to be fragmented by intermediate node, then setting DF bit (or dropping all IP fragments) will just not enable IKE to succeed. By not setting it we give IKE a chance. From svanru@gmail.com Mon Oct 28 23:27:31 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5E921F9E44; Mon, 28 Oct 2013 23:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0HVwrVYUQco; Mon, 28 Oct 2013 23:27:30 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2013911E81C1; Mon, 28 Oct 2013 23:27:24 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id x18so3649588lbi.2 for ; Mon, 28 Oct 2013 23:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=FP/sXu7k+fMseXEr0In8S9/+VgfMv3VavZlVCXm5aFI=; b=FtQBf7CXwJfsvv72A7mGg0E+cwhqziX+ExTPLbO/OxKyywXwklVG8Ti1es3JPmWy2l PYCS6QHBCOICl+cehYNPk46BA7G0rOpzxmVl++owNxHiIlAbodOTvv0K2cqYNhnLxTUY auGSFzNTrChEpgha76KbNzvNPxcNFtcq3PoH2V39Ew1JkHhs++kcKUK7t8myUAUwG1mb NkPUN14tF4HHeu2Mvp5wuO4KOcX+wiNsQ2pdufDYSvin6PNa2RvVHqH5jws3xhInJ11J hG50ULO/N49Gdi4AF0W7c5SpH4lLMfSwIWkmD0ruaxdQY08r6WSVd/c19o0DCQCOXiCY 3Viw== X-Received: by 10.152.10.99 with SMTP id h3mr14514449lab.13.1383028044056; Mon, 28 Oct 2013 23:27:24 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vo1sm15441589lbb.1.2013.10.28.23.27.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 28 Oct 2013 23:27:23 -0700 (PDT) Message-ID: <336D6D662DB0470DBFB3A576FFCB8E7F@buildpc> From: "Valery Smyslov" To: "Matt Mathis" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu><14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu><5268060B.4060604@isi.edu><81953CE6126542A8AD40207921B8E018@buildpc><52695365.4070803@isi.edu><526AD233.3090109@isi.edu> Date: Tue, 29 Oct 2013 10:27:20 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_056F_01CED491.732A1FD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Tue, 29 Oct 2013 05:02:07 -0700 Cc: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 06:27:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_056F_01CED491.732A1FD0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable While I agree with you in general, I think that IKE has its own = peculiarity, that makes things a bit different. There is a difference between IPv6 and IPv4. In IPv6 one can assume, that packets below 1280 bytes will not be fragmented en route. This = leaves enough room to make IKE level fragmentation and be sure, that no IP fragmentation = will take place. With IPv4 any IP packet greater 68 bytes is fragmentable. Due to IKE = message construction restrictions you cannot make IKE fragments that small, so you always have a possibility, that packets will still be fragmented = by IP level. If you send them with DF=3D1 and intermediate device still wants to = fragment them, then you will just prevent IKE to succeed with 100% probability. If in = this case DF=3D0, then it might work. If, as you suggest, originating host performs IP fragmentation and sends = IP fragments with DF=3D1, then we have exactly the problem the draft is intended to = solve -=20 the presence of IP fragments on the whole path. Draft introduces = IKE-level fragmentation=20 to avoid IP fragmentation whenever possible and to only let it be if it = is impossible. But if it=20 is unavoidable, then there are more chances for IKE to work if IP = fragments exist only on the part of the path, i.e. when fragmentation is done by = intermediate device. ----- Original Message -----=20 From: Matt Mathis=20 To: Valery Smyslov=20 Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; = draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org = ; Joe Touch=20 Sent: Tuesday, October 29, 2013 2:22 AM Subject: Re: [tsvwg] [IPsec] TSVDIR-ish = reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 Setting DF is supposed to prevent some midpath IPv4 device from = silently "fixing" a MTU problem by doing you a favor that you don't = want. IPv4 fragmentation can be used in a mode that mimics IPv6: Only = fragment on the originating host, always set DF on on all outbound = packets, even if they are already fragmented. Any protocol or = application that does not work in this configuration will also fail on = IPv6. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our = services to speak in defiance of unjust governments. We treat privacy = and security as matters of life and death, because for some users, they = are. On Sun, Oct 27, 2013 at 10:50 PM, Valery Smyslov = wrote: Hi Matt, the whole idea of the draft is avoiding IP fragmentation for IKE = when it prevents IKE to work. What about DF bit - I don't see how setting = it=20 would help IKE to work. Regards, Valery. ----- Original Message -----=20 From: Matt Mathis=20 To: Valery Smyslov=20 Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; = draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org = ; Joe Touch=20 Sent: Saturday, October 26, 2013 12:41 AM Subject: Re: [tsvwg] [IPsec] TSVDIR-ish = reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 I concur with Joe: once you have enough machinery work well with = IPv6 fragmentation semantics, you should use it for IPv4 too, and = unconditionally set DF. This probably applies to *all* protocols.=20 IPv4 reassembly is hopelessly out of scale. IP ID wrap times are = likely to be sub second for any large CGN connecting to any large = service..... They might even be shorter than the queuing times.=20 I suspect that if you re-review decade old papers on = fragmentation, you will find some scale assumptions that are no longer = correct. In that time the Internet has moved at least another two = orders of magnitude in packet rates. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using = our services to speak in defiance of unjust governments. We treat = privacy and security as matters of life and death, because for some = users, they are. On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch wrote: On 10/24/2013 10:45 PM, Valery Smyslov wrote: ... You're using existing IKE messages *and* existing timeouts = to determine when there is a problem. A separate timer would be = useful, if only to allow you to decouple fragment retransmission = from IKE transaction retries. No, the timeouts are different. I should have made it more = expplicit in the draft. That'd be useful. ... Always setting DF bit in this case will probably increase the = delay before IKE SA is set up (as more probes will need to be done). Except that if you continue to allow IP fragmentation, you can't = claim your solution is robust to IP fragment poisoning. Note, that this approach is in line with advices, given = for IKE in the paper C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on = Computer and Communications Security, October 2003. That paper doesn't consider IKE-level fragmentation, which = you're introducing. I agree that DF=3D0 for IKE without IKE-level = fragmentation. It does, in Section 3.3. Sorry - I missed that. But that section also gives good reasons = why this is a bad idea in IKE too. Joe ------=_NextPart_000_056F_01CED491.732A1FD0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
While I agree with you in general, I think that IKE = has its=20 own peculiarity,
that makes things a bit different.
 
There is a difference between IPv6 and IPv4. In IPv6 = one can=20 assume,
that packets below 1280 bytes will not be fragmented = en route.=20 This leaves enough room
to make IKE level fragmentation and be sure, that no = IP=20 fragmentation will take place.
With IPv4 any IP packet greater 68 bytes is = fragmentable. Due=20 to IKE message
construction restrictions you cannot make IKE = fragments that=20 small,
so you always have a possibility, that packets will = still be=20 fragmented by IP level.
If you send them with DF=3D1 and intermediate device = still wants=20 to fragment them,
then you will just prevent IKE to succeed with 100%=20 probability. If in this case DF=3D0,
then it might work.
 
If, as you suggest, originating host performs IP = fragmentation=20 and sends IP fragments
with DF=3D1, then we have exactly the problem the = draft is=20 intended to solve -
the presence of IP fragments on the whole path. = Draft=20 introduces IKE-level fragmentation
to avoid IP fragmentation whenever=20 possible and to only let it be if it is impossible. But if it =
is unavoidable, then there are more chances for IKE = to work if=20 IP fragments exist
only on the part of the path, i.e. when=20 fragmentation is done by intermediate device.
 
----- Original Message -----
From:=20 Matt=20 Mathis
Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; dra= ft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org=20 ; tsv-dir@ietf.org ; Joe Touch
Sent: Tuesday, October 29, 2013 = 2:22=20 AM
Subject: Re: [tsvwg] [IPsec] = TSVDIR-ish=20 reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

Setting DF is supposed to prevent some midpath IPv4 = device from=20 silently "fixing" a MTU problem by doing you a favor that you don't = want.

IPv4 fragmentation can be used in a mode that mimics IPv6: Only = fragment=20 on the originating host, always set DF on on all outbound packets, = even if=20 they are already fragmented.     Any protocol or application = that=20 does not work in this configuration will also fail on = IPv6.

Thanks,
--MM--
The best way to predict the future is to = create=20 it.  - Alan Kay

Privacy matters!  We know from recent = events=20 that people are using our services to speak in defiance of unjust = governments.=20   We treat privacy and security as matters of life and death, = because for=20 some users, they are.


On Sun, Oct 27, 2013 at 10:50 PM, Valery = Smyslov <svanru@gmail.com> wrote:
Hi Matt,
 
the whole idea of the draft is avoiding IP = fragmentation=20 for IKE when
it prevents IKE to work. What about=20 DF bit - I don't see how setting it
would help IKE to work.
 
Regards,
Valery.
 
----- Original Message ----- =
From: = Matt Mathis
Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org = ; draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org= ;=20 tsv-dir@ietf.org ; Joe Touch
Sent: Saturday, October 26, = 2013=20 12:41 AM
Subject: Re: [tsvwg] = [IPsec]=20 TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

I concur with Joe: once you have enough machinery = work well=20 with IPv6 fragmentation semantics, you should use it for IPv4 too, = and=20 unconditionally set DF.   This probably applies to *all* = protocols.=20

IPv4 reassembly is hopelessly out of scale.  IP ID wrap = times=20 are likely to be sub second for any large CGN connecting to any = large=20 service.....  They might even be shorter than the queuing = times.=20

I suspect that if you re-review decade old papers on = fragmentation,=20 you will find some scale assumptions that are no longer correct. =  In=20 that time the Internet has moved at least another two orders of = magnitude=20 in packet rates.

Thanks,
--MM--
The best way to predict the future is = to=20 create it.  - Alan Kay

Privacy matters!  We know = from=20 recent events that people are using our services to speak in = defiance of=20 unjust governments.   We treat privacy and security as = matters of=20 life and death, because for some users, they = are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe = Touch <touch@isi.edu> wrote:


On 10/24/2013 10:45 PM, Valery Smyslov = wrote:
...
You're using existing IKE messages *and* = existing=20 timeouts to
determine when there is a problem. A separate = timer=20 would be useful,
if only to allow you to decouple = fragment=20 retransmission from IKE
transaction=20 retries.

No, the timeouts are = different. I=20 should have made it more expplicit in
the=20 draft.

That'd be useful.

...
Always setting DF bit in this case will = probably=20 increase the delay
before IKE SA is set up (as more probes = will=20 need to be done).

Except that if you = continue to=20 allow IP fragmentation, you can't claim your solution is robust = to IP=20 fragment poisoning.

Note, that this approach is in line with = advices, given for IKE in the
paper

C. Kaufman, = R.=20 Perlman, and B. Sommerfeld, "DoS protection
  =  =20           for UDP-based = protocols", ACM=20 Conference on Computer and
        =  =20     Communications Security, October=20 2003.

That paper doesn't consider = IKE-level=20 fragmentation, which you're
introducing. I agree that = DF=3D0 for=20 IKE without IKE-level = fragmentation.

It=20 does, in Section 3.3.

Sorry - I missed = that. But=20 that section also gives good reasons why this is a bad idea in = IKE=20 too.

Joe


------=_NextPart_000_056F_01CED491.732A1FD0-- From kivinen@iki.fi Tue Oct 29 07:03:20 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796AB11E815F; Tue, 29 Oct 2013 07:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB4BA36gGTkF; Tue, 29 Oct 2013 07:03:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7536711E8258; Tue, 29 Oct 2013 07:03:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9TE3BN8021593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Oct 2013 16:03:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9TE3AFW029376; Tue, 29 Oct 2013 16:03:10 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21103.49182.48692.325305@fireball.kivinen.iki.fi> Date: Tue, 29 Oct 2013 16:03:10 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <336D6D662DB0470DBFB3A576FFCB8E7F@buildpc> References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <336D6D662DB0470DBFB3A576FFCB8E7F@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Cc: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, Matt Mathis , tsv-dir@ietf.org Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 14:03:20 -0000 Valery Smyslov writes: > Draft introduces IKE-level fragmentation to avoid IP fragmentation > whenever possible and to only let it be if it is impossible. Actually the first preference is to use IP fragmentation, and if that works, it is what we use, and we do not try IKE fragmentation at all. Only if the large packets do not go through then we try to enable IKE fragmentation and so on... So all of this draft is used only if there is some device on the path that will drop at least some fragments somewhere. And yes, we might miscategorize some network errors as IP fragments getting lost, as we have no indication from the network whether the packet was lost because it got fragmented on the IP level, or for some reasons. There is no way IKEv2 could even get that information, so we assume that if multiple full size retransmission of IKEv2 packets are lost, then there might be fragmentation issue, and we enable IKE fragmentation. > But if it is unavoidable, then there are more chances for IKE to > work if IP fragments exist only on the part of the path, i.e. when > fragmentation is done by intermediate device. Yep. -- kivinen@iki.fi From lsmt@ietf.org Tue Oct 29 08:37:42 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35A021E8176; Tue, 29 Oct 2013 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd14edzJsHCk; Tue, 29 Oct 2013 08:37:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5803221E8151; Tue, 29 Oct 2013 08:37:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Gorry Fairhurst , David Black , James Polk X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131029153731.8811.69364.idtracker@ietfa.amsl.com> Date: Tue, 29 Oct 2013 08:37:31 -0700 X-Mailman-Approved-At: Tue, 29 Oct 2013 09:22:13 -0700 Cc: Martin Stiemerling , tsvwg@ietf.org Subject: [tsvwg] New Liaison Statement, "Liaison reply to "Development of Informative Codepoint mapping in ITU-T Study Group 12" [to IETF TSV]" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 15:37:42 -0000 Title: Liaison reply to "Development of Informative Codepoint mapping in IT= U-T Study Group 12" [to IETF TSV] Submission Date: 2013-10-25 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1287/ From: ITU-T Study Group 12, Q17/12 (Hiroshi Ota ) To: Transport Area Working Group (Gorry Fairhurst , D= avid Black , James Polk ) Cc: Martin Stiemerling ,Spencer Dawkins ,tsvwg@ietf.org,acmorton@att.com Reponse Contact: = Technical Contact: = Purpose: For information Body: = Attachments: Liaison reply to "Development of Informative Codepoint mapping in ITU-T= Study Group 12" [to IETF TSV] https://datatracker.ietf.org/documents/LIAISON/liaison-2013-10-25-itu-t= -sg12-q-12-17-tsvwg-liaison-reply-to-development-of-informative-codepoint-m= apping-in-itu-t-study-group-12-to-ietf-tsv-attachment-1.pdf From gorry@erg.abdn.ac.uk Thu Oct 31 01:07:41 2013 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304BE21E80DC for ; Thu, 31 Oct 2013 01:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.555 X-Spam-Level: X-Spam-Status: No, score=-105.555 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfwDQP7Gmv4p for ; Thu, 31 Oct 2013 01:07:34 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED5411E8133 for ; Thu, 31 Oct 2013 01:06:56 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 52F8F2B44B3 for ; Thu, 31 Oct 2013 08:06:54 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 31 Oct 2013 08:06:54 -0000 Message-ID: <24fad5c1a2d85e83597b936e4492f17a.squirrel@www.erg.abdn.ac.uk> Date: Thu, 31 Oct 2013 08:06:54 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tsvwg] Presenters: Copies of slides needed for tsvwg at ietf-88 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 08:07:42 -0000 If you are listed in the Agenda for tsvwg (see below), please send slides to the Chair by Sunday noon, so that these may be uploaded for the meeting: http://www.ietf.org/proceedings/88/agenda/agenda-88-tsvwg Uploading draft slides ahead of the actual tsvwg meeting is really helpful for our remote participants - even if the slide deck may need minor adjustment prior to the meeting. Gorry