From nobody Mon Jan 4 10:57:14 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFDA3A0FD7; Mon, 4 Jan 2021 10:57:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Bernie Volz via Datatracker To: Cc: draft-ietf-quic-transport.all@ietf.org, last-call@ietf.org, quic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160978663285.3066.12060742286583829825@ietfa.amsl.com> Reply-To: Bernie Volz Date: Mon, 04 Jan 2021 10:57:12 -0800 Archived-At: Subject: [Int-dir] Intdir telechat review of draft-ietf-quic-transport-33 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 18:57:13 -0000 Reviewer: Bernie Volz Review result: Ready I am an assigned INT directorate reviewer for draft-ietf-quic-transport-33. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/. Based on my review, if I was on the IESG I would ballot this document as NO OBJECTION. There is a lot here and the document seems well put together and thorough. I didn’t notice any major or even minor issues with the document – it looks like it has had lots of careful review to date. (The one minor typo is “version” is misspelled as “verion” in the “DO NOT DEPLOY THIS VERSION OF QUIC” text, which will be removed anyway.) I also reviewed the document for the items listed at https://trac.ietf.org/trac/int/wiki/IntAreaIssues and the document fully supports IPv6 (it support both IPv4 and IPv6 equally), deal with MTU and fragmentation properly, and has no other issues listed at this link. Therefore, I think this document is ready to advance. - Bernie Volz From nobody Mon Jan 4 12:10:50 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FBC3A1016; Mon, 4 Jan 2021 12:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.72 X-Spam-Level: X-Spam-Status: No, score=-7.72 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=RDuZXNqk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pqFZYS8A Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6sZaOby8VLD; Mon, 4 Jan 2021 12:10:44 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F573A1018; Mon, 4 Jan 2021 12:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3104; q=dns/txt; s=iport; t=1609791044; x=1611000644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dP8pMegX3lSzpFHTwKHTaPNdwsEX3KLw6aeWK+5ywgI=; b=RDuZXNqkM88L9mx1ANVuY6xdnr0ZufwljpjN2uvh9/0lCty/uUXaiomk jiEanZheHhW0UOu9TwBDMA6TkKAF28FKnxxd0qyJgV87a+TUp1WpF9S3F 2FVx/6Rr35SbS1qUP7/yUelZQYKHrBV3ADyY9gbxrRHMiny5qmkmymspe o=; X-IPAS-Result: =?us-ascii?q?A0A8AAC6c/NfkJJdJa1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?TwGAQELAYFSUX1bLy6EP4NIA40/JQOZDYEuFIERA1QLAQEBDQEBGAsKAgQBA?= =?us-ascii?q?YRKAheBWAIlNQgOAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBhjgMhXMBA?= =?us-ascii?q?QEEAQEQEREMAQEsCwELBAIBCBEDAQIDAiYCAgIlCxQBCAgCBAENBSKDBAGCV?= =?us-ascii?q?QMuAQ4+o0sCgTyIaXaBMoMEAQEGhQQYghADBoEOKgGCdIN8gRuFHSYbgUE/g?= =?us-ascii?q?TgMEIJWPoJdAQEDgUKDMjSCLIMoBFMUDi4LJBhKHgYLAZAFgz2lGwqCdokqg?= =?us-ascii?q?SCKf3aFGQMfg2OebZQLixCRUxKEPgIEAgQFAg4BAQaBWAMzgVlwFTsqAYIKA?= =?us-ascii?q?TNQFwINjiEag1eFFIVEdDcCBgEJAQEDCXyNHgEB?= IronPort-PHdr: =?us-ascii?q?9a23=3As7HtsRBsB2ZT9mafu8asUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00A3CXJ7Q7LRPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGE8flbFqUqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,474,1599523200"; d="scan'208";a="622752611" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Jan 2021 20:10:43 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 104KAgDY008913 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Jan 2021 20:10:43 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 Jan 2021 14:10:42 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 Jan 2021 14:10:42 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 4 Jan 2021 14:10:42 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H1fm4/LWRaNh2550eHRAl9dNZ+pZUio6Jl+BZmQm0XIg8zGVZWZ4bL9dqGiJkrOMwaGdQR7EHDhd00hGQoh34xpA5PEB53JjvrM59d9LjnqRrVvas/xud7XKPoAdnJMFqQgj2fhjdJy1yunubJ+/9MWAq8qVGtXGNx1zlDodT00T38J6QS99M5aD9Q8BV1H5YFARNcOHRUi7cb9ziSSKcLy+UQpdnPxbnahrzok+eOn3hrbBmk7XSf21nmomO9+bgx8S+TNntALZlCy3HMMJvOLzA6TIvLKXUkS5XZ6+m+o10RT+/8lDkbFgaQEswzOo0LNC1MddU6tO7H6wG76WqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dP8pMegX3lSzpFHTwKHTaPNdwsEX3KLw6aeWK+5ywgI=; b=C3mlSH0PrzwWQKQllJYzI9TbV6zvVUc0Jo3C3JqRMXWknWS0au6GMtkovWo2NCcnpbewx0+lmZSZh5x0jN0PqNUpx2PL2U0CeDfnhKESy8p5GRkzhmgtNFCXaQRM4XO7nM1xKkEEoa8Zdhc3OaGJtpspvsYtb1KOef/qLgEVpuyotiApHeOlOMch6AOofB4RiDYlgV/poIdcWpZTxq9zxReSc3Na0v9nnTeQInYHmf0iWO/VOSEVhzAfVU0/ch4/nng03yhgocD/BNPHupEIBLv5m/Syc2P91FygZuC49nbC+U6vNXl3176usdswhZOfiR0DE0xJ11JM83uDX3fvZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dP8pMegX3lSzpFHTwKHTaPNdwsEX3KLw6aeWK+5ywgI=; b=pqFZYS8AtctU3CNs0RjqpODHq95LSpzWMQqRNNibqFAYb34lPbr3Jim1z3ERncZGRi8BCzLXDkNKTfJLhfm5XLQOiDuRusQ9AzYpPlHeQojkLfyUb2zTbeEngcFatYb0cpeBh/2zuFqG/vqCMQv7rYfnPb+aMt9ZSIxHsv+FEXo= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5031.namprd11.prod.outlook.com (2603:10b6:510:33::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.20; Mon, 4 Jan 2021 20:10:41 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3721.024; Mon, 4 Jan 2021 20:10:41 +0000 From: "Eric Vyncke (evyncke)" To: "Bernie Volz (volz)" , "int-dir@ietf.org" CC: "last-call@ietf.org" , "quic@ietf.org" , "draft-ietf-quic-transport.all@ietf.org" Thread-Topic: [Int-dir] Intdir telechat review of draft-ietf-quic-transport-33 Thread-Index: AQHW4stwh+Yf3sxpbky1sqZjOhhZ5KoX9oUA Date: Mon, 4 Jan 2021 20:10:41 +0000 Message-ID: <6E70C105-963E-4039-9375-02A4F968B5AC@cisco.com> References: <160978663285.3066.12060742286583829825@ietfa.amsl.com> In-Reply-To: <160978663285.3066.12060742286583829825@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.44.20121301 authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:10a7:265c:e618:887] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9359a4a1-ac89-4620-cd31-08d8b0eccf7f x-ms-traffictypediagnostic: PH0PR11MB5031: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dAPKHnkIPIVGVV7y5khevXInKVW4CihXLo9KgsSpc31S1dAsgcZ0pnEWlIQKsHU+9Hf/EbKXXndi6skPS2dVGnw5FAHa6g7s2tHaxSgUPbLXfr4tsUQ1QjaghI3w8UErrrzG9U45jfBJ3O5BwJaQaJ90bVhGwmjsKccmqxCQbAte6zXis3vWYYp5l6r9TN5n5YJt3glVxlVTAFBeS3bGRX5dMUDW5QAU5kMDZBnRsOVXTmYylyE0GcsjOoKQ6AzENr2xkd9UyiWJsTJ3FlgN7K8g7EnysmCPzcTX5DIkXEErNz1e5qYZVmk8kU6b2BNM5LQJ2R9yK9R2ovASnHBYckImTECZFbHnBf7PE6SWZbw5Lo2r9mORIsL66AXpJjaNXWu1LK63ObtXokjz+K1xSaatBwo7t7yL6MXvcxGxLwqv9agAm5QR0jfAYf7Ner5wmeE25iW9UCkc3Ev19sIGEuwfjhZX4HcxJh4uY7VWlFMaUJnpe4cW/C9baQcUNZ0pEnqhqljhd55lC/1jEkOESg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(376002)(346002)(366004)(39860400002)(450100002)(2906002)(71200400001)(33656002)(316002)(110136005)(2616005)(36756003)(4326008)(478600001)(966005)(8676002)(54906003)(6506007)(86362001)(5660300002)(6486002)(66446008)(76116006)(186003)(66946007)(8936002)(91956017)(83380400001)(64756008)(53546011)(66574015)(66556008)(66476007)(6512007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?aUMzZnd0YWdocGw4UXNJQU9Pb1RvRG9rSzA5QXpXQTl6V3k5SnBEbE9NWFZa?= =?utf-8?B?SlhNTlo1K0pLWHIvdjVYeW9RTWM5OGZFYzBUOU5sQS93OUdnQm1pTUJpVTF4?= =?utf-8?B?Q2VqaTNaMjgvSTZMdEhWZFdoelF3cWxjUUpOK1V4c3RLejk4WTU0cWRJUm03?= =?utf-8?B?TjhTMmpWajhwS1R3eFl6R21zbWJWdE9kOFNuTlhxSDlpYStHRU5BZGM0VUZz?= =?utf-8?B?YzlUM1EvbjIydjRLNCtRV0RrNmlta28xWTNGVURTSmlTTk81TzUrN1JZTHc4?= =?utf-8?B?L3NMSnlKQ1VqeG5ITkR6MGRzcVU4aCtaVGZRQXdMakFFcWJxQ1RacU1SMEJh?= =?utf-8?B?V00wR3gzSWN6NEtKbCtUZE5VVmpkU1g1QVllTTQxbWM3RW05bXo2N3hHSnJo?= =?utf-8?B?aVJJSWl0UGpaMldhK05RSXJHSi9DM1FHSjBqRGs1M0FxaW5pNVp5QlpjMVNy?= =?utf-8?B?QUorN3YwTWNvVmlLTVR0dHg4cWdEeFdpWHNsbjFGa2RWNkVCQmQzRGhUV3l2?= =?utf-8?B?ZmE1QmpMTE1HU0RRZ0VrYzM5c2xTcnh5cy92Zmc5TElDcXZROExJSmRIR2c5?= =?utf-8?B?dHMzNlhyeGNwMnRGWGFKemNkRUpiWllwQkFqQVFVK2V6NWdEYXlidkY2ODhN?= =?utf-8?B?L1dWOWhuaHorNjFyTFRVZENidDNicE11NjhYZXlLL2VwS3c4SDc5WVMydm16?= =?utf-8?B?ZzV5YWdVblBiSDdiWC85TGFPdzY1RzBpSE1GdHpDaTIvL2NLUVIyM0RndUFM?= =?utf-8?B?bm80UGRjOFZIMWIxL0toVzlwQ0VmSkVRc0d5OTY3aTdkVTR3UDZIdk11M2hJ?= =?utf-8?B?V2JOcVVua2F0amxLNzZTYTZQOVRhRHZWUE5rNC9BUktPT1cyM051ekVybEM2?= =?utf-8?B?UlM0UFNhU0ZicFErMXBPMXNwZEZGQ1FpWDFneFlJUXpPN2hXQ0Y0a1RNRHhy?= =?utf-8?B?bndzaHZoa0FralU1RjM5Q3BDR2xrdVoxM3hkNFcwSStyM1Jnd2VIRGFGeHZV?= =?utf-8?B?Q3dwY0JpVzhEOFZGQUlUbFNiS3RlYzQzdlJhRzVKVXB1a3NuMUFwYkR4dU82?= =?utf-8?B?S0loblF3RS95M3kveTNBQVF6RUlqd3pVZnMvTGtqK3pRd1NPa2ZlY3NGUFRU?= =?utf-8?B?SmY4Q3Bpb3RmY1NaU1JySVFFd2lna2pTUUVZWUR4S3dFYkxQb3dqbnJneXBl?= =?utf-8?B?aVpVMlZiM3JPZ2Q3TUFOdzFpcnVCN1hIMGZNcVREQnBSVTFlMmI1bTFpQTBW?= =?utf-8?B?cFFyeVAwcmtybC91NURpUUFNU01icUNtQk5PRUtTTVhWQWNVQm9WY20xeFhx?= =?utf-8?B?VlNIODRuOTNNNTM5QmNDSzByV2hrdTZrR09Yb09OMHF1RnlVT0hGL0xzc0I0?= =?utf-8?B?TDd2WlU5eGlidEVXMTMwR1pFdEtKMHI3ZmtnZHdFVFI0bFdpckFtT3RuMjEx?= =?utf-8?Q?fLngl4O6?= Content-Type: text/plain; charset="utf-8" Content-ID: <7856319DA82F434DB763C1DB9825DED0@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9359a4a1-ac89-4620-cd31-08d8b0eccf7f X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2021 20:10:41.1889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R9TztRe/4QYhTufYLEB8Oxz7xhWHVimHk38ocT5zoI+HhUJ5kjJSMHezurw7k10eLxQmqfHab8sg243RZNZZmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5031 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-quic-transport-33 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 20:10:46 -0000 QmVybmllDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHRoaXMgaW50ZXJuZXQgZGlyZWN0b3Jh dGUgcmV2aWV3IG9mIHRoaXMgaHVnZSBidXQgYWxzbyBmdW5kYW1lbnRhbCBhbmQgaW1wb3J0YW50 IGRvY3VtZW50LCBJIGRvZXMgaGVscCBtZSB3aXRoIG15IG93biByZXZpZXcuDQoNClJlZ2FyZHMN Cg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJbnQtZGly IDxpbnQtZGlyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBCZXJuaWUgVm9seiB2aWEg RGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQpSZXBseS1UbzogIkJlcm5pZSBWb2x6ICh2 b2x6KSIgPHZvbHpAY2lzY28uY29tPg0KRGF0ZTogTW9uZGF5LCA0IEphbnVhcnkgMjAyMSBhdCAx OTo1Nw0KVG86ICJpbnQtZGlyQGlldGYub3JnIiA8aW50LWRpckBpZXRmLm9yZz4NCkNjOiAibGFz dC1jYWxsQGlldGYub3JnIiA8bGFzdC1jYWxsQGlldGYub3JnPiwgInF1aWNAaWV0Zi5vcmciIDxx dWljQGlldGYub3JnPiwgImRyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQuYWxsQGlldGYub3JnIiA8 ZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC5hbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSW50LWRp cl0gSW50ZGlyIHRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTMz DQoNCiAgICBSZXZpZXdlcjogQmVybmllIFZvbHoNCiAgICBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0K DQogICAgSSBhbSBhbiBhc3NpZ25lZCBJTlQgZGlyZWN0b3JhdGUgcmV2aWV3ZXIgZm9yIGRyYWZ0 LWlldGYtcXVpYy10cmFuc3BvcnQtMzMuDQogICAgVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVu IHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0IEFyZWENCiAgICBEaXJl Y3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5kIHNoZXBoZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVz ZSBjb21tZW50cyBqdXN0DQogICAgbGlrZSB0aGV5IHdvdWxkIHRyZWF0IGNvbW1lbnRzIGZyb20g YW55IG90aGVyIElFVEYgY29udHJpYnV0b3JzIGFuZCByZXNvbHZlDQogICAgdGhlbSBhbG9uZyB3 aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQu IEZvciBtb3JlDQogICAgZGV0YWlscyBvbiB0aGUgSU5UIERpcmVjdG9yYXRlLCBzZWUNCiAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2dyb3VwL2ludGRpci9hYm91dC8uDQoNCiAgICBC YXNlZCBvbiBteSByZXZpZXcsIGlmIEkgd2FzIG9uIHRoZSBJRVNHIEkgd291bGQgYmFsbG90IHRo aXMgZG9jdW1lbnQgYXMgTk8NCiAgICBPQkpFQ1RJT04uDQoNCiAgICBUaGVyZSBpcyBhIGxvdCBo ZXJlIGFuZCB0aGUgZG9jdW1lbnQgc2VlbXMgd2VsbCBwdXQgdG9nZXRoZXIgYW5kIHRob3JvdWdo Lg0KDQogICAgSSBkaWRu4oCZdCBub3RpY2UgYW55IG1ham9yIG9yIGV2ZW4gbWlub3IgaXNzdWVz IHdpdGggdGhlIGRvY3VtZW50IOKAkyBpdCBsb29rcw0KICAgIGxpa2UgaXQgaGFzIGhhZCBsb3Rz IG9mIGNhcmVmdWwgcmV2aWV3IHRvIGRhdGUuIChUaGUgb25lIG1pbm9yIHR5cG8gaXMNCiAgICDi gJx2ZXJzaW9u4oCdIGlzIG1pc3NwZWxsZWQgYXMg4oCcdmVyaW9u4oCdIGluIHRoZSDigJxETyBO T1QgREVQTE9ZIFRISVMgVkVSU0lPTiBPRiBRVUlD4oCdDQogICAgdGV4dCwgd2hpY2ggd2lsbCBi ZSByZW1vdmVkIGFueXdheS4pDQoNCiAgICBJIGFsc28gcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGZv ciB0aGUgaXRlbXMgbGlzdGVkIGF0DQogICAgaHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvaW50 L3dpa2kvSW50QXJlYUlzc3VlcyBhbmQgdGhlIGRvY3VtZW50IGZ1bGx5DQogICAgc3VwcG9ydHMg SVB2NiAoaXQgc3VwcG9ydCBib3RoIElQdjQgYW5kIElQdjYgZXF1YWxseSksIGRlYWwgd2l0aCBN VFUgYW5kDQogICAgZnJhZ21lbnRhdGlvbiBwcm9wZXJseSwgYW5kIGhhcyBubyBvdGhlciBpc3N1 ZXMgbGlzdGVkIGF0IHRoaXMgbGluay4NCg0KICAgIFRoZXJlZm9yZSwgSSB0aGluayB0aGlzIGRv Y3VtZW50IGlzIHJlYWR5IHRvIGFkdmFuY2UuDQoNCiAgICAtICAgICAgIEJlcm5pZSBWb2x6DQoN Cg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICBJbnQtZGlyIG1haWxpbmcgbGlzdA0KICAgIEludC1kaXJAaWV0Zi5vcmcNCiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1kaXINCg0K From nobody Wed Jan 20 12:51:59 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB6E3A149D; Wed, 20 Jan 2021 12:51:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Jean-Michel Combes via Datatracker To: Cc: bess@ietf.org, draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161117591453.11763.14808972528115094239@ietfa.amsl.com> Reply-To: Jean-Michel Combes Date: Wed, 20 Jan 2021 12:51:54 -0800 Archived-At: Subject: [Int-dir] Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 20:51:55 -0000 Reviewer: Jean-Michel Combes Review result: Almost Ready Hi, Please find my review, as member of the INT Area Directorate, of the following document: *** GENERAL COMMENT(S)/QUESTION(S) *** o Forwarding a packet I am not aware of EVPN mechanisms: for this review, I am assuming that EVPN allows a PE to forward a packet when the CE owning the MAC destination address and the CE owning the MAC source address are not on the same L2 link. If my assumption is wrong, that should change deeply my review. o State of the art There are no reference to RFC 4349 and RFC 6957, at least. Previous works have been done on “Proxy-ND” and potential issues already analyzed/solved. Please my comments/questions inside: - Section 3.6 - Section 6 *** DEEP REVIEW *** BESS Workgroup J. Rabadan, Ed. Internet-Draft S. Sathappan Updates: 7432 (if approved) K. Nagaraj Intended status: Standards Track G. Hankins Expires: July 11, 2021 Nokia T. King DE-CIX January 7, 2021 Operational Aspects of Proxy-ARP/ND in EVPN Networks draft-ietf-bess-evpn-proxy-arp-nd-11 1. Terminology BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic. BD: Broadcast Domain. ARP: Address Resolution Protocol. GARP: Gratuitous ARP message. ND: Neighbor Discovery Protocol. NS: Neighbor Solicitation message. NA: Neighbor Advertisement. IXP: Internet eXchange Point. IXP-LAN: the IXP's large Broadcast Domain to where Internet routers are connected. DC: Data Center. IP->MAC: an IP address associated to a MAC address. IP->MAC entries are programmed in Proxy-ARP/ND tables and may be of three different types: dynamic, static or EVPN-learned. SN-multicast address: Solicited-Node IPv6 multicast address used by NS messages. NUD: Neighbor Unreachability Detection, as per [RFC4861]. DAD: Duplicate Address Detection, as per [RFC4861]. SLLA: Source Link Layer Address, as per [RFC4861]. TLLA: Target Link Layer Address, as per [RFC4861]. R Flag: Router Flag in NA messages, as per [RFC4861]. O Flag: Override Flag in NA messages, as per [RFC4861]. S Flag: Solicited Flag in NA messages, as per [RFC4861]. RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per [RFC7432]. MAC or IP DA: MAC or IP Destination Address. MAC or IP SA: MAC or IP Source Address. AS-MAC: Anti-spoofing MAC. LAG: Link Aggregation Group. BD: Broadcast Domain. BD is already defined at the beginning of the list. 3. Solution Description As PE3 learns more and more host entries in the Proxy-ARP/ND table, the flooding of ARP Request messages is reduced and in some cases it can even be suppressed. In a network where most of the participant CEs are not moving between PEs and they advertise their presence with GARPs or unsolicited NA messages, the ARP/ND flooding as well as the unknown unicast flooding can practically be suppressed. In an EVPN- based IXP network, where all the entries are Static, the ARP/ND flooding is in fact totally suppressed. IMHO, it is not possible to suppress ALL ND flooding: Duplicate Address Detection (DAD) is remaining, even when the entries are all Static: cf. RFC 4862, Section 5.4. The Proxy-ARP/ND function can be structured in six sub-functions or procedures: 1. Learning sub-function 2. Reply sub-function 3. Unicast-forward sub-function 4. Maintenance sub-function 5. Flooding reduction/suppression sub-function 6. Duplicate IP detection sub-function A Proxy-ARP/ND implementation MAY support all those sub-functions or only a subset of them. The following sections describe each individual sub-function. No sub-function is mandatory to have “Proxy-ARP/ND” working correctly? If not, please, add text saying which ones MUST be implemented. 3.2. Reply Sub-Function This sub-function will reply to Address Resolution requests/ solicitations upon successful lookup in the Proxy-ARP/ND table for a given IP address. The following considerations should be taken into account: a. When replying to ARP Request or NS messages, the PE SHOULD use the Proxy-ARP/ND entry MAC address as MAC SA. This is RECOMMENDED so that the resolved MAC can be learned in the MAC FIB of potential layer-2 switches sitting between the PE and the CE requesting the Address Resolution. What is the IP source address in the NA message? What is the Target link-layer address in the NA message? 3.3. Unicast-forward Sub-Function As discussed in Section 3.2, in some cases the operator may want to 'unicast-forward' certain ARP-Request and NS messages as opposed to reply to them. The operator SHOULD be able to activate this option with one of the following parameters: a. unicast-forward always b. unicast-forward unknown-options If 'unicast-forward always' is enabled, the PE will perform a Proxy- ARP/ND table lookup and in case of a hit, the PE will forward the packet to the owner of the MAC found in the Proxy-ARP/ND table. This is irrespective of the options carried in the ARP/ND packet. This option provides total transparency in the BD and yet reduces the amount of flooding significantly. If 'unicast-forward unknown-options' is enabled, upon a successful Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' action only if the ARP-Request or NS messages carry unknown options, as explained in Section 3.2. The 'unicast-forward unknown-options' configuration allows the support of new applications using ARP/ND in the BD while still reducing the flooding. What happens, for these two options, when there is no hit inside “Proxy-ARP/ND Table”? 3.5. Flooding (to Remote PEs) Reduction/Suppression The Proxy-ARP/ND function implicitly helps reducing the flooding of ARP Request and NS messages to remote PEs in an EVPN network. However, in certain use-cases, the flooding of ARP/NS/NA messages (and even the unknown unicast flooding) to remote PEs can be suppressed completely in an EVPN network. For instance, in an IXP network, since all the participant CEs are well known and will not move to a different PE, the IP->MAC entries may be all provisioned by a management system. Assuming the entries for the CEs are all provisioned on the local PE, a given Proxy-ARP/ND table will only contain static and EVPN-learned entries. In this case, the operator may choose to suppress the flooding of ARP/NS/NA to remote PEs completely. Cf. my comment about DAD in section 3. 3.6. Duplicate IP Detection The Proxy-ARP/ND function SHOULD support duplicate IP detection so that ARP/ND-spoofing attacks or duplicate IPs due to human errors can be detected. Duplicate Address Detection is mandatory: s/SHOULD/MUST IMHO, it would be useful to add text explaining why RFC 6957 doesn’t solve your issues and so you need to specify a solution “from scratch”. 5.1. All Dynamic Learning In this scenario for minimum security and mitigation, EVPN is deployed in the peering network with the Proxy-ARP/ND function shutdown. PEs do not intercept ARP/ND requests and flood all requests, as in a conventional layer-2 network. ND messages are IP based: s/layer-2/layer-3 6. Security Considerations The solution also provides protection against Denial Of Service attacks that use ARP/ND-spoofing as a first step. The Duplicate IP Detection and the use of an AS-MAC as explained in Section 3.6 protects the BD against ARP/ND spoofing. You are assuming that the attacker and the victim are not on the same L2-Link. Is it always the case in your scenarios (i.e., only P2P links between PE and CE)? If not, IMHO, it would better to: - s/protects/mitigates - Add text explaining when there is a protection and when there is no protection. I would some text about the fact that your proposal cannot/will not work if there is a (current or future) security mechanism securing ARP/ND exchanges (e.g., SEND) because the PE is not able to secure "proxied" ND messages (i.e., with SEND, the PE is not aware of the security credentials linked to an IP address). Thanks in advance for your replies. Best regards, JMC. From nobody Wed Jan 20 14:29:03 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963C93A1591; Wed, 20 Jan 2021 14:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=e6VbKDir; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iZsfjsWp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn39bp6ecvqQ; Wed, 20 Jan 2021 14:28:59 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1A8E3A1590; Wed, 20 Jan 2021 14:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27539; q=dns/txt; s=iport; t=1611181738; x=1612391338; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vj8MiuSbqbuVHy63frfTRCGqUB3CzRlAkpQDmwvhyF8=; b=e6VbKDirILxI5Bkcl09b6hwoWqfB/XFJg7k1llTITxAv91DkJ7RMpXXa BN7sxAC6w12ImG3aOQyddtOvrkxPaFyCk1L85hf5MhRAfoALwPL764R4r 8lc0jJwHoAqFH8eEvt1QyxuhteiFwZymqXMEG33jxPNZ01g6q5oOh/56k I=; X-IPAS-Result: =?us-ascii?q?A0DFAgBwrQhgmIUNJK1iHQEBAQEJARIBBQUBQIFPgSMBL?= =?us-ascii?q?yMufVsvL4gIA44FA4EFjguKA4FCgREDVAsBAQENAQEYAQoKAgQBAYRKAoF3A?= =?us-ascii?q?iU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAQEBhjYMhXMBAQEEAQElG?= =?us-ascii?q?QEBJQYBCwEPAgEILQsOJwslAgQBDQUIE4MLAYF+UgUDLgEOpkQCiiV0gQEzg?= =?us-ascii?q?wUBAQaFCxiCEQMGgTiCdopEJhuBQT+BEUOBWEk1PoJdAQGBGEkFJhKDDoIsg?= =?us-ascii?q?U8KaQZQEAQaMQgUDg0hCyQZPAcBBQcXERQFBkGPT4pZi1SSIwqCd5ZOhTyDK?= =?us-ascii?q?ooylRKUG50aAoQ0AgICAgQFAg4BAQaBbSEsgS1wFTuCaVAXAg1XjUoag1eFF?= =?us-ascii?q?IVEdDcCBgEJAQEDCXyLNAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AVjNy0x3P4nos2hHzsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGv6dsgUPHG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK6PFRbXsHkaA6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,362,1602547200"; d="scan'208,217";a="671493154" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jan 2021 22:28:57 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 10KMSvIG029223 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2021 22:28:57 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 Jan 2021 16:28:57 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 20 Jan 2021 16:28:56 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 20 Jan 2021 17:28:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iRaIPp5SVtMwEqqJAooxmKJQolT5yUoJ08hk0nWYh9vCvuQLi7NlG3jZG0Y2pQgXHsd8cFWuAKo+GfFiWFx9LOGn6XpSAxK2vdEIYNkHkqYZAFIpjfoje7UqqA9iFBc0uuRvUT6bQVD9uiTOaYg518VcfboLoKRlqd/PNicciT5nio+LfhWHM7vsuGhOeGv10tlPbQm6XDFRnKz3poOhwpYkvopuLTPg4AVmCGCI2Rq2bVDoJGXPvlUg3WohoPk2CV27D2otAer6jqUkaoqmGW3/R/IhMKUkdtpjK7Ger2BRlIWPE9ajoIJsHSTlE5zomgNv6YMgN/ELg/6V5Y32Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N8KnJ0u7SHZSH9j8eszwEEFmRp9BCs4H4EPKy6NUyzU=; b=aNDglEubvdGKMcEzbS7LNWENC4jM6d+9Z/kKY0qVuPX+xSd3oJOOB9uCgWHl3fTFZ7XJdcFk6ih1y1HJt3EPABV267a5liup7+gLxlL4rRAjX+4WruFRjpyrtiX0ukTqfignTYYQSomnVh+kxqqV+m08kKLp686qs3kStk/+YMvA4W/sG39KJFe+F340WFCCpc4CxA49spTRsQH03P2rbGzbyYtXfKWFDIormqjgRnkGF1AYi3EiIamYz3yD4a9ZgLcjojcQ//bNwCQhUGyDgtQC9QnPjgEO3diDamO6XKbT5/hNn6wgGpxmtDNanA6UBZnFFtxBMqIUkYoW+lC/ng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N8KnJ0u7SHZSH9j8eszwEEFmRp9BCs4H4EPKy6NUyzU=; b=iZsfjsWp8LTCtqeKyjhIsW+kV8ytEC132aHVteHh/aHqIAU7QFr6FQ27O65DiP71ZI9MwZ8I2EGHVX8YT0wrJ3Fs9hV+8FMgTbOVhFAFUAUzND6UgS7KYmbtr6qIAT0u1nPfCI5xV+faZzf27+W27Kx96mlSQY3SOkUnlpOF/F0= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4805.namprd11.prod.outlook.com (2603:10b6:510:32::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12; Wed, 20 Jan 2021 22:28:55 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::7d4c:6b05:89aa:85b%3]) with mapi id 15.20.3763.014; Wed, 20 Jan 2021 22:28:55 +0000 From: "Eric Vyncke (evyncke)" To: "int-dir@ietf.org" , Jean-Michel Combes CC: "draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org" Thread-Topic: [Int-dir] Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11 Thread-Index: AQHW724rg9kaZnVDsEuxtqR0aM35XaoxGBmE Date: Wed, 20 Jan 2021 22:28:55 +0000 Message-ID: References: <161117591453.11763.14808972528115094239@ietfa.amsl.com> In-Reply-To: <161117591453.11763.14808972528115094239@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: fr-BE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:61b3:36cb:af41:f268] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 36f8a825-0902-49e8-3163-08d8bd92c5b1 x-ms-traffictypediagnostic: PH0PR11MB4805: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3KSBiCiW47AVxCb3EI6Q14UaDf0J3qAbT76DFU7Wc83sWJwJnXacU3NEEegtcYo/puvsaOo5YLXIB3OApZhpAhu3a4G3HcyxYVh4hSB7D7Dhz0NwzleIPuNzoOz8Hr/Vh/sNQzwrguG6FjZ6TiE/uYbp4UFq+JFfyxG1Rc9IrtuV1Zl9BOR52HiLzqh9Zgl6fsUlOAAZxabMVWxpMTSwrfcMFq3UI2eFZzj6u227FVjQ+uNTFatAP6bQ4SvxuWSMtq6i58c/A9YWoVOe1T8DxKeHsSZ0Tm+fkgALwqPFU/qDQ82szGMfBG3uapivHsWKJ2O5vdIimERpmHqLr0Di7x0uNr2fTCGYYJcx9JOYtP6kWfHpETkfxK1uQYOFO89hypXWrsZ2W6oDtB+BtmrvOc0XnAGi2MyAzQP6QtxCNNt8dsNerJk9PXH5D5kGHFRQ7l5jpiLcFmNklxP73kqVqA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(376002)(39860400002)(346002)(396003)(7696005)(166002)(4326008)(8676002)(9686003)(71200400001)(966005)(19627405001)(55016002)(110136005)(66574015)(76116006)(83380400001)(33656002)(52536014)(6506007)(186003)(5660300002)(8936002)(478600001)(316002)(2906002)(66556008)(64756008)(66476007)(66946007)(66446008)(91956017)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?oHVdcPPrNyhvayDoX4Bu2iadmgas7IIrDVli+ubq5bdlcMxrLDytrgIQ?= =?Windows-1252?Q?Px2RSjhv046r5kwohArHilbv9YCorveyA32zlf3tSY7BT46bnaCYPkwF?= =?Windows-1252?Q?L8jEuTU/jfFHINhNwn+3AjxWG+Ul6B0Q8WkdFeF3Ufk6QdtIyPKtVF4A?= =?Windows-1252?Q?s133SgEGXAVsG/aij7/AWi5jKTBsKKWGqKEyEKbKKnIi6IvRdvIEK11A?= =?Windows-1252?Q?HCE9KbPXfRNyhmKIEsQr/NbSn3xYthqeain8EE7GGu0a0z2RGAnsJgDQ?= =?Windows-1252?Q?8/sEf9V90J5hrWDlM8l6hFOAJncawiI5xxuth3VFvOFacgYmKJVOFnH1?= =?Windows-1252?Q?yQ7mewk2/y+GLKRe62Czz57Ynz+B4zgTsKstpblKUB8zx10cbE/0l/p0?= =?Windows-1252?Q?bpNOsX2Tfe2etDR2NDXtXF+IVkLY9SsmkNmXQ58F4O/9Goo0Xr3IsGRM?= =?Windows-1252?Q?gWIT/s5jADzgZTDffrN+c02cTTU+zFOEBe3ZB2YEY/CxjcOAQJt6RlLa?= =?Windows-1252?Q?W3B93jivVKqgTZtN0gWNTfPT5G/19Q7OT1HlZcVMLZ+ieMtwdDlnPsVN?= =?Windows-1252?Q?C3z2+fQeV4BX8QXqs/0LDQS+dlUUBA+DO6yyfOLT/DaXHV4i8Y64k/57?= =?Windows-1252?Q?jWbAAG1JEmT1fnYuIE+bKP+I5zWnXcV5ML1WpCzh/5rEwwD2/mPQn+zw?= =?Windows-1252?Q?bekxRJ/INqs0kUcGZiVefl3c4m+fl0h124ZPJOveUuErVG4fQjqWeF5R?= =?Windows-1252?Q?iKblOkM+LBdEyyONUdpIJct6hz76mC0h+J1vPbvR/TEnGQDt2STszyU4?= =?Windows-1252?Q?gNWX9xxTn27vB3SHnux4RORbzMxHAM7wyh/Ek/Or/YB7IiagnIqGTvld?= =?Windows-1252?Q?mq6ioXakvBkxilUIl5GsNWFR2jVkVypK2LTpDMb7bzA//3RspqNREWUX?= =?Windows-1252?Q?t8yF4DTd6c1CfVYKCnbJc+d156IRfHL6/Yt+FkUZtRv8rSjKSjroweyd?= =?Windows-1252?Q?1oZ+t2b4NGQYN0t+JQ8gHXp/8e6bPEDYIsBiEJruZNrs70ylsKJGrvE6?= =?Windows-1252?Q?aurYE77j+BD5gxMBftX8UzBL6r559qt/6I3yMAecHI8iBD20h+1aRDQ7?= =?Windows-1252?Q?Neo=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PH0PR11MB49663A3D92DB5D5A24B41D95A9A20PH0PR11MB4966namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36f8a825-0902-49e8-3163-08d8bd92c5b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2021 22:28:55.1379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LiXot4SQK0f1mI4dHZALGXT6SdHJtRm6lJmDee+5hDY6sX6qHqrK0XAVb3xID0AObO5ib9kUrlFDJXuJwJcpOA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4805 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 22:29:02 -0000 --_000_PH0PR11MB49663A3D92DB5D5A24B41D95A9A20PH0PR11MB4966namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jean-Michel Merci Thanks a lot for the review, I will use it when doing my IESG ballot. This = kind of review is really helpful regards Bien =E0 toi -=E9ric ________________________________ De : Int-dir de la part de Jean-Michel Combes vi= a Datatracker Envoy=E9 : mercredi 20 janvier 2021 21:51 =C0 : int-dir@ietf.org Cc : draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org ; bess@ietf.org ; last-call@ietf.or= g Objet : [Int-dir] Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-= nd-11 Reviewer: Jean-Michel Combes Review result: Almost Ready Hi, Please find my review, as member of the INT Area Directorate, of the follow= ing document: *** GENERAL COMMENT(S)/QUESTION(S) *** o Forwarding a packet I am not aware of EVPN mechanisms: for this review, I am assuming that EVPN allows a PE to forward a packet when the CE owning the MAC destination addr= ess and the CE owning the MAC source address are not on the same L2 link. If my assumption is wrong, that should change deeply my review. o State of the art There are no reference to RFC 4349 and RFC 6957, at least. Previous works have been done on =93Proxy-ND=94 and potential issues alread= y analyzed/solved. Please my comments/questions inside: - Section 3.6 - Secti= on 6 *** DEEP REVIEW *** BESS Workgroup J. Rabadan, Ed. Internet-Draft S. Sathappan Updates: 7432 (if approved) K. Nagaraj Intended status: Standards Track G. Hankins Expires: July 11, 2021 Nokia T. King DE-CIX January 7, 2021 Operational Aspects of Proxy-ARP/ND in EVPN Networks draft-ietf-bess-evpn-proxy-arp-nd-11 1. Terminology BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic. BD: Broadcast Domain. ARP: Address Resolution Protocol. GARP: Gratuitous ARP message. ND: Neighbor Discovery Protocol. NS: Neighbor Solicitation message. NA: Neighbor Advertisement. IXP: Internet eXchange Point. IXP-LAN: the IXP's large Broadcast Domain to where Internet routers are connected. DC: Data Center. IP->MAC: an IP address associated to a MAC address. IP->MAC entries are programmed in Proxy-ARP/ND tables and may be of three different types: dynamic, static or EVPN-learned. SN-multicast address: Solicited-Node IPv6 multicast address used by NS messages. NUD: Neighbor Unreachability Detection, as per [RFC4861]. DAD: Duplicate Address Detection, as per [RFC4861]. SLLA: Source Link Layer Address, as per [RFC4861]. TLLA: Target Link Layer Address, as per [RFC4861]. R Flag: Router Flag in NA messages, as per [RFC4861]. O Flag: Override Flag in NA messages, as per [RFC4861]. S Flag: Solicited Flag in NA messages, as per [RFC4861]. RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per [RFC7432]. MAC or IP DA: MAC or IP Destination Address. MAC or IP SA: MAC or IP Source Address. AS-MAC: Anti-spoofing MAC. LAG: Link Aggregation Group. BD: Broadcast Domain. BD is already defined at the beginning of the list. 3. Solution Description As PE3 learns more and more host entries in the Proxy-ARP/ND table, the flooding of ARP Request messages is reduced and in some cases it can even be suppressed. In a network where most of the participant CEs are not moving between PEs and they advertise their presence with GARPs or unsolicited NA messages, the ARP/ND flooding as well as the unknown unicast flooding can practically be suppressed. In an EVPN- based IXP network, where all the entries are Static, the ARP/ND flooding is in fact totally suppressed. IMHO, it is not possible to suppress ALL ND flooding: Duplicate Address Detection (DAD) is remaining, even when the entries are all Static: cf. RFC 4862, Section 5.4. The Proxy-ARP/ND function can be structured in six sub-functions or procedures: 1. Learning sub-function 2. Reply sub-function 3. Unicast-forward sub-function 4. Maintenance sub-function 5. Flooding reduction/suppression sub-function 6. Duplicate IP detection sub-function A Proxy-ARP/ND implementation MAY support all those sub-functions or only a subset of them. The following sections describe each individual sub-function. No sub-function is mandatory to have =93Proxy-ARP/ND=94 working correctly? If not, please, add text saying which ones MUST be implemented. 3.2. Reply Sub-Function This sub-function will reply to Address Resolution requests/ solicitations upon successful lookup in the Proxy-ARP/ND table for a given IP address. The following considerations should be taken into account: a. When replying to ARP Request or NS messages, the PE SHOULD use the Proxy-ARP/ND entry MAC address as MAC SA. This is RECOMMENDED so that the resolved MAC can be learned in the MAC FIB of potential layer-2 switches sitting between the PE and the CE requesting the Address Resolution. What is the IP source address in the NA message? What is the Target link-layer address in the NA message? 3.3. Unicast-forward Sub-Function As discussed in Section 3.2, in some cases the operator may want to 'unicast-forward' certain ARP-Request and NS messages as opposed to reply to them. The operator SHOULD be able to activate this option with one of the following parameters: a. unicast-forward always b. unicast-forward unknown-options If 'unicast-forward always' is enabled, the PE will perform a Proxy- ARP/ND table lookup and in case of a hit, the PE will forward the packet to the owner of the MAC found in the Proxy-ARP/ND table. This is irrespective of the options carried in the ARP/ND packet. This option provides total transparency in the BD and yet reduces the amount of flooding significantly. If 'unicast-forward unknown-options' is enabled, upon a successful Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' action only if the ARP-Request or NS messages carry unknown options, as explained in Section 3.2. The 'unicast-forward unknown-options' configuration allows the support of new applications using ARP/ND in the BD while still reducing the flooding. What happens, for these two options, when there is no hit inside =93Proxy-A= RP/ND Table=94? 3.5. Flooding (to Remote PEs) Reduction/Suppression The Proxy-ARP/ND function implicitly helps reducing the flooding of ARP Request and NS messages to remote PEs in an EVPN network. However, in certain use-cases, the flooding of ARP/NS/NA messages (and even the unknown unicast flooding) to remote PEs can be suppressed completely in an EVPN network. For instance, in an IXP network, since all the participant CEs are well known and will not move to a different PE, the IP->MAC entries may be all provisioned by a management system. Assuming the entries for the CEs are all provisioned on the local PE, a given Proxy-ARP/ND table will only contain static and EVPN-learned entries. In this case, the operator may choose to suppress the flooding of ARP/NS/NA to remote PEs completely. Cf. my comment about DAD in section 3. 3.6. Duplicate IP Detection The Proxy-ARP/ND function SHOULD support duplicate IP detection so that ARP/ND-spoofing attacks or duplicate IPs due to human errors can be detected. Duplicate Address Detection is mandatory: s/SHOULD/MUST IMHO, it would be useful to add text explaining why RFC 6957 doesn=92t solv= e your issues and so you need to specify a solution =93from scratch=94. 5.1. All Dynamic Learning In this scenario for minimum security and mitigation, EVPN is deployed in the peering network with the Proxy-ARP/ND function shutdown. PEs do not intercept ARP/ND requests and flood all requests, as in a conventional layer-2 network. ND messages are IP based: s/layer-2/layer-3 6. Security Considerations The solution also provides protection against Denial Of Service attacks that use ARP/ND-spoofing as a first step. The Duplicate IP Detection and the use of an AS-MAC as explained in Section 3.6 protects the BD against ARP/ND spoofing. You are assuming that the attacker and the victim are not on the same L2-Li= nk. Is it always the case in your scenarios (i.e., only P2P links between PE an= d CE)? If not, IMHO, it would better to: - s/protects/mitigates - Add text explaining when there is a protection and when there is no protection. I would some text about the fact that your proposal cannot/will not work if there is a (current or future) security mechanism securing ARP/ND exchanges (e.g., SEND) because the PE is not able to secure "proxied" ND messages (i.= e., with SEND, the PE is not aware of the security credentials linked to an IP address). Thanks in advance for your replies. Best regards, JMC. _______________________________________________ Int-dir mailing list Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir --_000_PH0PR11MB49663A3D92DB5D5A24B41D95A9A20PH0PR11MB4966namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Jean-Michel

Merci
Thanks a lot for the review, I will use it when doing my IESG ballot. This = kind of review is really helpful

regards
Bien =E0 toi

-=E9ric

De : Int-dir <int-dir-bo= unces@ietf.org> de la part de Jean-Michel Combes via Datatracker <nor= eply@ietf.org>
Envoy=E9 : mercredi 20 janvier 2021 21:51
=C0 : int-dir@ietf.org <int-dir@ietf.org>
Cc : draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org <draft-i= etf-bess-evpn-proxy-arp-nd.all@ietf.org>; bess@ietf.org <bess@ietf.or= g>; last-call@ietf.org <last-call@ietf.org>
Objet : [Int-dir] Intdir telechat review of draft-ietf-bess-evpn-pro= xy-arp-nd-11
 
Reviewer: Jean-Michel Combes
Review result: Almost Ready

Hi,

Please find my review, as member of the INT Area Directorate, of the follow= ing
document:

*** GENERAL COMMENT(S)/QUESTION(S) ***
o Forwarding a packet
I am not aware of EVPN mechanisms: for this review, I am assuming that EVPN=
allows a PE to forward a packet when the CE owning the MAC destination addr= ess
and the CE owning the MAC source address are not on the same L2 link. If my=
assumption is wrong, that should change deeply my review.

o State of the art
There are no reference to RFC 4349 and RFC 6957, at least.
Previous works have been done on =93Proxy-ND=94 and potential issues alread= y
analyzed/solved. Please my comments/questions inside: - Section 3.6 - Secti= on 6

*** DEEP REVIEW ***

BESS Workgroup          &= nbsp;           &nbs= p;            &= nbsp;       J. Rabadan, Ed.
Internet-Draft          &= nbsp;           &nbs= p;            &= nbsp;          S. Sathappan Updates: 7432 (if approved)        =             &nb= sp;            =   K. Nagaraj
Intended status: Standards Track       &= nbsp;           &nbs= p;          G. Hankins
Expires: July 11, 2021         = ;            &n= bsp;            = ;           Nokia
            &nb= sp;            =             &nb= sp;            =             &nb= sp;  T. King
            &nb= sp;            =             &nb= sp;            =             &nb= sp;   DE-CIX
            &nb= sp;            =             &nb= sp;            =        January 7, 2021

          Operational Aspects = of Proxy-ARP/ND in EVPN Networks
            &nb= sp;     draft-ietf-bess-evpn-proxy-arp-nd-11

<snip>

1.  Terminology

<snip>

   BCP14 [RFC2119] [RFC8174] when, and only when, they appear in = all
   capitals, as shown here.

   BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic.=

   BD: Broadcast Domain.

   ARP: Address Resolution Protocol.

   GARP: Gratuitous ARP message.

   ND: Neighbor Discovery Protocol.

   NS: Neighbor Solicitation message.

   NA: Neighbor Advertisement.

   IXP: Internet eXchange Point.

   IXP-LAN: the IXP's large Broadcast Domain to where Internet ro= uters
   are connected.

   DC: Data Center.

   IP->MAC: an IP address associated to a MAC address.  I= P->MAC entries
   are programmed in Proxy-ARP/ND tables and may be of three diff= erent
   types: dynamic, static or EVPN-learned.

   SN-multicast address: Solicited-Node IPv6 multicast address us= ed by
   NS messages.

   NUD: Neighbor Unreachability Detection, as per [RFC4861].

   DAD: Duplicate Address Detection, as per [RFC4861].

   SLLA: Source Link Layer Address, as per [RFC4861].

   TLLA: Target Link Layer Address, as per [RFC4861].

   R Flag: Router Flag in NA messages, as per [RFC4861].

   O Flag: Override Flag in NA messages, as per [RFC4861].

   S Flag: Solicited Flag in NA messages, as per [RFC4861].

   RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as = per
   [RFC7432].

   MAC or IP DA: MAC or IP Destination Address.

   MAC or IP SA: MAC or IP Source Address.

   AS-MAC: Anti-spoofing MAC.

   LAG: Link Aggregation Group.

   BD: Broadcast Domain.

<JMC>
BD is already defined at the beginning of the list.
</JMC>

<snip>

3.  Solution Description

<snip>

   As PE3 learns more and more host entries in the Proxy-ARP/ND t= able,
   the flooding of ARP Request messages is reduced and in some ca= ses it
   can even be suppressed.  In a network where most of the p= articipant
   CEs are not moving between PEs and they advertise their presen= ce with
   GARPs or unsolicited NA messages, the ARP/ND flooding as well = as the
   unknown unicast flooding can practically be suppressed.  = In an EVPN-
   based IXP network, where all the entries are Static, the ARP/N= D
   flooding is in fact totally suppressed.

<JMC>
IMHO, it is not possible to suppress ALL ND flooding: Duplicate Address
Detection (DAD) is remaining, even when the entries are all Static: cf. RFC=
4862, Section 5.4. </JMC>

   The Proxy-ARP/ND function can be structured in six sub-functio= ns or
   procedures:

   1.  Learning sub-function

   2.  Reply sub-function

   3.  Unicast-forward sub-function

   4.  Maintenance sub-function

   5.  Flooding reduction/suppression sub-function

   6.  Duplicate IP detection sub-function

   A Proxy-ARP/ND implementation MAY support all those sub-functi= ons or
   only a subset of them.  The following sections describe e= ach
   individual sub-function.

<JMC>
No sub-function is mandatory to have =93Proxy-ARP/ND=94 working correctly?<= br> If not, please, add text saying which ones MUST be implemented.
</JMC>

<snip>

3.2.  Reply Sub-Function

   This sub-function will reply to Address Resolution requests/    solicitations upon successful lookup in the Proxy-ARP/ND table= for a
   given IP address.  The following considerations should be= taken into
   account:

   a.  When replying to ARP Request or NS messages, the PE S= HOULD use
       the Proxy-ARP/ND entry MAC address as = MAC SA.  This is
       RECOMMENDED so that the resolved MAC c= an be learned in the MAC
       FIB of potential layer-2 switches sitt= ing between the PE and the
       CE requesting the Address Resolution.<= br>
<JMC>
What is the IP source address in the NA message?
What is the Target link-layer address in the NA message?
</JMC>

  <snip>

3.3.  Unicast-forward Sub-Function

   As discussed in Section 3.2, in some cases the operator may wa= nt to
   'unicast-forward' certain ARP-Request and NS messages as oppos= ed to
   reply to them.  The operator SHOULD be able to activate t= his option
   with one of the following parameters:

   a.  unicast-forward always

   b.  unicast-forward unknown-options

   If 'unicast-forward always' is enabled, the PE will perform a = Proxy-
   ARP/ND table lookup and in case of a hit, the PE will forward = the
   packet to the owner of the MAC found in the Proxy-ARP/ND table= .  This
   is irrespective of the options carried in the ARP/ND packet.&n= bsp; This
   option provides total transparency in the BD and yet reduces t= he
   amount of flooding significantly.

   If 'unicast-forward unknown-options' is enabled, upon a succes= sful
   Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' a= ction
   only if the ARP-Request or NS messages carry unknown options, = as
   explained in Section 3.2.  The 'unicast-forward unknown-o= ptions'
   configuration allows the support of new applications using ARP= /ND in
   the BD while still reducing the flooding.

<JMC>
What happens, for these two options, when there is no hit inside =93Proxy-A= RP/ND
Table=94? </JMC>

<snip>

3.5.  Flooding (to Remote PEs) Reduction/Suppression

   The Proxy-ARP/ND function implicitly helps reducing the floodi= ng of
   ARP Request and NS messages to remote PEs in an EVPN network.<= br>    However, in certain use-cases, the flooding of ARP/NS/NA messa= ges
   (and even the unknown unicast flooding) to remote PEs can be    suppressed completely in an EVPN network.

   For instance, in an IXP network, since all the participant CEs= are
   well known and will not move to a different PE, the IP->MAC= entries
   may be all provisioned by a management system.  Assuming = the entries
   for the CEs are all provisioned on the local PE, a given Proxy= -ARP/ND
   table will only contain static and EVPN-learned entries. = In this
   case, the operator may choose to suppress the flooding of ARP/= NS/NA
   to remote PEs completely.

<JMC>
Cf. my comment about DAD in section 3.
</JMC>

<snip>

3.6.  Duplicate IP Detection

   The Proxy-ARP/ND function SHOULD support duplicate IP detectio= n so
   that ARP/ND-spoofing attacks or duplicate IPs due to human err= ors can
   be detected.

<JMC>
Duplicate Address Detection is mandatory: s/SHOULD/MUST
IMHO, it would be useful to add text explaining why RFC 6957 doesn=92t solv= e your
issues and so you need to specify a solution =93from scratch=94. </JMC&g= t;

<snip>

5.1.  All Dynamic Learning

   In this scenario for minimum security and mitigation, EVPN is<= br>    deployed in the peering network with the Proxy-ARP/ND function=
   shutdown.  PEs do not intercept ARP/ND requests and flood= all
   requests, as in a conventional layer-2 network.

<JMC>
ND messages are IP based:
s/layer-2/layer-3
</JMC>

<snip>

6.  Security Considerations

<snip>

   The solution also provides protection against Denial Of Servic= e
   attacks that use ARP/ND-spoofing as a first step.  The Du= plicate IP
   Detection and the use of an AS-MAC as explained in Section 3.6=
   protects the BD against ARP/ND spoofing.

<JMC>
You are assuming that the attacker and the victim are not on the same L2-Li= nk.
Is it always the case in your scenarios (i.e., only P2P links between PE an= d
CE)? If not, IMHO, it would better to: - s/protects/mitigates - Add text explaining when there is a protection and when there is no protection. <= /JMC>

<JMC>
I would some text about the fact that your proposal cannot/will not work if=
there is a (current or future) security mechanism securing ARP/ND exchanges=
(e.g., SEND) because the PE is not able to secure "proxied" ND me= ssages (i.e.,
with SEND, the PE is not aware of the security credentials linked to an IP<= br> address). </JMC>

<snip>

Thanks in advance for your replies.

Best regards,

JMC.



_______________________________________________
Int-dir mailing list
Int-dir@ietf.org
https://www.ietf.= org/mailman/listinfo/int-dir
--_000_PH0PR11MB49663A3D92DB5D5A24B41D95A9A20PH0PR11MB4966namp_--