Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)

Eric Rosen <erosen@juniper.net> Thu, 15 November 2018 18:07 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08DB130E08; Thu, 15 Nov 2018 10:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level:
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 LYcuGwcpmHWs; Thu, 15 Nov 2018 10:07:46 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1640130E02; Thu, 15 Nov 2018 10:07:46 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wAFI4jeW001719; Thu, 15 Nov 2018 10:07:46 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=f1uiVq+kkRPrLidyG4rPxvbS3ndPnaADJ0nTsNMLlHk=; b=loQxZLkPdsYd+bXooYJAI1X58A6sdlm6FrS3hSiMT7LUn/AvrsTMNnQqIobtxlTw8K6j eTpzAt09SdUMYEavLQavMXTYln2SiuL0TnebQoaXXESn/A7uRUHSD7kQbHbrBF+1yRvj XdJZO3IsHfrNgroEChOIuYrIyS4xRJmZt7Qznox/XyfebFX/lSp90c06K2oqN7EsI+5/ 8ilb9v5LavknYiCe7Jme+JfcNhyt8N8VzQumXLO6MhtQbFGdwOn0kahTQaKcKN6BmQCe OahCzkRxumidOqiKTYdMYGd9vfYw2syrSeX1p6rI8fZKSxXseOa+BHM6eygtFYw/LGxP sQ==
Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0015.outbound.protection.outlook.com [216.32.181.15]) by mx0a-00273201.pphosted.com with ESMTP id 2ns561h08a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Nov 2018 10:07:45 -0800
Received: from DM5PR0501MB3864.namprd05.prod.outlook.com (10.167.108.27) by DM5PR0501MB3687.namprd05.prod.outlook.com (10.167.107.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.15; Thu, 15 Nov 2018 18:07:43 +0000
Received: from DM5PR0501MB3864.namprd05.prod.outlook.com ([fe80::240d:b16e:5c81:9acf]) by DM5PR0501MB3864.namprd05.prod.outlook.com ([fe80::240d:b16e:5c81:9acf%5]) with mapi id 15.20.1339.019; Thu, 15 Nov 2018 18:07:43 +0000
From: Eric Rosen <erosen@juniper.net>
To: Mirja Kühlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
CC: "draft-ietf-bess-mvpn-expl-track@ietf.org" <draft-ietf-bess-mvpn-expl-track@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
Thread-Index: AQHUa5UZ4BVi+KGZCkWGLSL870TBIKVRRQUA
Date: Thu, 15 Nov 2018 18:07:43 +0000
Message-ID: <8de86550-39cd-8c4c-75ba-8e7a033fc907@juniper.net>
References: <154038410206.6927.15775732681687781010.idtracker@ietfa.amsl.com>
In-Reply-To: <154038410206.6927.15775732681687781010.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: BYAPR11CA0083.namprd11.prod.outlook.com (2603:10b6:a03:f4::24) To DM5PR0501MB3864.namprd05.prod.outlook.com (2603:10b6:4:7b::27)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR0501MB3687; 6:lXzqTP0J4yIGcrQbXL1C2FMsBwqd1N0d3xOlclRf8pEU4iUgh7F+hpcjuHjqiTYTWxte5ewBBFfHShmDm042pAzW6uk+iwKJwe0A2usgftMmOc+wSfWUGCmYq7+Ns0e4dFZcswSHjvo++iA1HzAwX3Danvx4GLs+FWD2o7CUQGOKOyehifvy1jXi1Iri9saqCM996LnS17l+DHtV4T9/tOnqRaCpZjF0GYBpLBbrg33rej3OTg2+mtH32XtZEUYLK19Uf4H/ZafZJMjNy54LBIDiSb725sgbLM74VWn/37UI+U7lIeozFcuCAaosMG2ej6AxZ84yye3XGTkFyt2rMvP2hr6eZvVuaMnOIrH9dIcQJIbqKyHv4cd24Y1rCHV+09reKWPIn6IbArVSe/f3V7vYmD7k4nLSDlF1ghkLrtPPuWgLb90eALYmEviZBbddS0qno5vpcjAFfy4/0e3sPA==; 5:w/cVKBH8T+6xq2sHM5UkyB/hmR2pDhmnVdoEd7ge+1ZOmai0bNTBCDJRst4Gzp6juPFdZfYT83tMlBFexfpy3Lbyd4fvWprrU3yg/X8I+mbDz91hg+xsj+TorWQRpMdAffR3gQmjNz8ylnaIVLlVMHRoq4ez+aCTZAm0rqIRXAs=; 7:+9vgjwpeS2QMcX7qH8TCup0af9OSlYbnAa9+6SyMoceq3iND3vRzmkwfT61KTza5ev37S+LVQ1e71yl/QEYGZxEROjyiasHcCe5EXurAgUqdB7eymtxHK1h45LGSebcoxJuOcZRqip7hKaUpW4G6UQ==
x-ms-office365-filtering-correlation-id: 836c6914-1641-4d2d-eccb-08d64b253d01
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM5PR0501MB3687;
x-ms-traffictypediagnostic: DM5PR0501MB3687:
x-microsoft-antispam-prvs: <DM5PR0501MB368745BC2E8C39600A525398D4DC0@DM5PR0501MB3687.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231415)(944501410)(52105112)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM5PR0501MB3687; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0501MB3687;
x-forefront-prvs: 08572BD77F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(366004)(136003)(39860400002)(199004)(189003)(78114003)(14454004)(6486002)(6246003)(6436002)(6512007)(53936002)(25786009)(81156014)(81166006)(68736007)(5660300001)(8936002)(5024004)(478600001)(2900100001)(256004)(229853002)(14444005)(4326008)(71190400001)(11346002)(66066001)(26005)(2906002)(53546011)(2616005)(31696002)(446003)(316002)(52116002)(110136005)(6506007)(6116002)(3846002)(99286004)(54906003)(71200400001)(97736004)(31686004)(36756003)(76176011)(102836004)(224303003)(105586002)(224313004)(106356001)(186003)(66574009)(7736002)(486006)(476003)(86362001)(305945005)(386003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0501MB3687; H:DM5PR0501MB3864.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: tsPw36RgHkK3YtTIh7QX37FXX2H2FhJ0llXFEXfv2sYPZbTnG9VWZ8ofPJQ8qRcQYLbzbLd+5Cv6jqINRwGjH/Eyel6r7uMx4V3U5s39jceA5KsN0xtnxtUWxIuIECVDxroayIC9jUdO5sxUcRISK9umrz9lrnjUJ/1x/AlXpgaZaJp6cJ1mKYVrHCOTuYbHOdESXRdtJod1BeWSdayamaAnqMZaAcpN7b5HNj1OhlkUODGhH7QCrKOVn9p+R/6AcqBcCCqaBWBKk0y+x5pDd13s3sN+LT6Hi6qHrDuU0Lut68N7eo9j/13m99deawYpmseWZUtLjE6xDOFl+F2YkFZ/GxIZCcWU5DUeIFynZ54=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <6AC356D7889F804A8BA1F13B2820B871@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 836c6914-1641-4d2d-eccb-08d64b253d01
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2018 18:07:43.6378 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3687
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-15_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811150158
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/oHvWdJBZ-Aab14l5pv9_yedhiXs>
Subject: Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 18:07:48 -0000

On 10/24/2018 8:28 AM, Mirja Kühlewind wrote:
> ---------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> In section 9 (security considerations):
> Thanks for discussing network load here! However, I find this sentence a bit
> unsatisfactory:
>     „The specification of counter-measures for this problem is outside the scope
>     of this document.“
> Isn’t there any easy way to make some more recommendations for counter measures
> that could be discussed here? E.g. implement some rate limiting or filtering.
> Or only accept LIR-PF request from preconfigured hosts (given that LIR-PF
> support must anyway be pre-configured)? I’m not an expert on this topic and
> therefore don’t know if any of such recommendations make sense, however, I
> would quickly like to discuss if it is potentially possible to say more than
> what’s current said. Thanks!

These particular suggestions don't really work in this context.

- The set of Provider Edge routers (PEs) that attach to a given VPN is 
always auto-discovered, never pre-configured.  That's an important part 
of the L3VPN value proposition.   There are already mechanisms in place 
to ensure that the S-PMSI A-D route gets sent only to the proper set of 
egress PEs.  Also, a properly functioning egress PE will only respond 
with a Leaf A-D route if it has already auto-discovered the ingress PE.  
(You might want to question the security of the L3VPN mechanisms, but 
that would certainly be outside the scope of this document .)

- Rate limiting the generation of Leaf A-D routes wouldn't work, because 
the problem is not that one PE generates too many, but that too many PEs 
may generate them.  Rate limiting the processing of received Leaf A-D 
routes is also problematic.  In normal operation, you might correctly 
get a whole bunch of them in quick succession, and if you don't process 
them in a timely manner, the customers will see a high multicast "join 
latency".

In the particular sort of attack mentioned in the Security 
Considerations section, an ingress PE originates an S-PMSI A-D route 
with LIR-pF clear, but somehow the bit gets set before the route is 
received by the egress PEs.   As Alvaro has suggested, if an attacker 
can modify the control messages, quite a bit of havoc can result, and 
the particular attack under discussion is just one of many that can 
occur if the control plane is not secure.  I can certainly put in a 
reference to RFCS 6192 and 7454 (as Alvaro suggests), if you think that 
is helpful.  Properly protecting the control plane should prevent this 
kind of attack.

In the event such an attack occurs, mitigating it is unfortunately not 
very straightforward.  The ingress node can take note of the fact that 
it is getting Leaf A-D routes with LIR-pF set, in response to an S-PMSI 
A-D route with LIR-pF clear.  Withdrawing the S-PMSI A-D route could put 
a stop to the attack.  However, there are a few problems with this:

- Under normal operation, there are some race conditions that may cause 
the ingress node to think it is being attacked, when in fact it is not.

- If some egress nodes have a bug that causes them to set LIR-pF when it 
should be clear, withdrawing the S-PMSI A-D route will stop the flow of 
multicast data traffic to all the egress nodes, causing an unnecessary 
customer-visible disruption.

- The same situation that caused the S-PMSI A-D route to be originated 
in the first place will still exist after the S-PMSI A-D route is 
withdrawn, so the route will just be re-originated.

In other words, any action that would ameliorate the effects of this 
sort of attack would have a negative effect during normal operation.  
Therefore it is really better to rely on security mechanisms that 
protect the control plane generally, rather than having a mechanism that 
is focused on this one particular type of attack.

We could say that if an ingress PE receives a Leaf A-D route with LIR-pF 
set, and that route is a response to an S-PMSI A-D route that did not 
have LIR-pF set, the event MUST be logged.  This would generate some 
noise in the log during normal operation, but could provide at least a 
hint that an attack is occurring.

What do you think?

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Some other minor comments:
>   1) section 2: „Use of this flag in the PTA carried by other route types is outside
>     the scope of this document.  Use of this flag in the PTA carried by
>     an S-PMSI A-D routes whose NLRI does not contain a wildcard is
>     outside the scope of this document.“
> Maybe you also want to say something like „The flag SHOULD be ignored in these cases.“..?

Agreed.

>
>   2) section 3
> s/The result (if any) is the match for tracking“/The result (if any) is the “match for tracking“/
> (missing quotes)

Fixed in the next revision.