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

Eric Rosen <erosen@juniper.net> Wed, 28 November 2018 17:15 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 1E86B130F8A; Wed, 28 Nov 2018 09:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.16
X-Spam-Level:
X-Spam-Status: No, score=-4.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 BqflT9zpxa4S; Wed, 28 Nov 2018 09:15:16 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 F3E3D130E8B; Wed, 28 Nov 2018 09:15:15 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wASGOqO5015164; Wed, 28 Nov 2018 08:31:13 -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=G18ZMTWzM0/CXiHHOUmK77r5prbuCfv8622l+VLYjXY=; b=CGxsQOni4fSiLcVpE3wsgL8dU8do+wHPcbC0UhEnyhqnUaRQwo+BOnBvoE8r82Dem3Mn GJMMCZ9YMSW0dDTWsZVsJb9IRwkth03Ewo/jOIIEZyinm3atWVobRBXYoAMi7Qeb6/OD oWymE18cv6RgHu9oHDBE5M3Y4UkQWeDIpkZHk0PkWunca9KV26HQ99LcD/X2Wh19yqWG +Jz/2trnwXt1QwShAf2NGIlGQQ6q20+KxYM8bUcq8/sFP+bmLI5fLo7IgfVyVFiN8tsL JiVnZbihPVf0MddnWK4y1wTccak65jNsuWtMleEArX183WLDhJCFKumzSP0LrdVmSs5s kw==
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0184.outbound.protection.outlook.com [216.32.180.184]) by mx0b-00273201.pphosted.com with ESMTP id 2p1x7ag1jc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Nov 2018 08:31:13 -0800
Received: from DM5PR0501MB3864.namprd05.prod.outlook.com (10.167.108.27) by DM5PR0501MB3816.namprd05.prod.outlook.com (10.167.108.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.12; Wed, 28 Nov 2018 16:31:09 +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.1361.019; Wed, 28 Nov 2018 16:31:09 +0000
From: Eric Rosen <erosen@juniper.net>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
CC: The IESG <iesg@ietf.org>, "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: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1iZXNz?= =?utf-8?Q?-mvpn-expl-track-12:_(with_DISCUSS_and_COMMENT)?=
Thread-Index: AQHUa5UZ4BVi+KGZCkWGLSL870TBIKVRRQUAgBEFdACAA03hgA==
Date: Wed, 28 Nov 2018 16:31:09 +0000
Message-ID: <86feca33-cabe-8826-5a34-84bac5556baa@juniper.net>
References: <154038410206.6927.15775732681687781010.idtracker@ietfa.amsl.com> <8de86550-39cd-8c4c-75ba-8e7a033fc907@juniper.net> <B680F2EC-7F28-4CC5-ABE6-4547B4BDD028@kuehlewind.net>
In-Reply-To: <B680F2EC-7F28-4CC5-ABE6-4547B4BDD028@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: BYAPR11CA0091.namprd11.prod.outlook.com (2603:10b6:a03:f4::32) To DM5PR0501MB3864.namprd05.prod.outlook.com (2603:10b6:4:7b::27)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR0501MB3816; 6:JXn0GqmGg6vGrnNSLlAqo8uqAyTAgT4JLNeUVb52de4blijMlsKcYMYHUCLIEOwzsSDKcOEzI6GkvRIorXcTK1lsMRjFeCDgBtBgtVLaPmNk6J0Xxv2GqSF6rTenjaIwgalmNNpk2KRK212e/JKrgurVzkO72PwZX/HfzE+xl4UX+81B2SNrizlZHmgCEOKm6NYGfOpUJuVqV5qJ3a7qGM2Q3tLuEWGaQ2Il6Tp9KqAG/ez3s7Gq36JBkXh2Ff2/uftVtvUwe8LurgROOpPFkgHJIL5txmn2y8Y0RatgsSYjZjSwoYnGx/9L6oA9d4cgKSg1xFJz7u5j2K88eGtcX/E3KKf67IFDUCyd+WqXFlbbzh6uOCwZGpsy5sl2ExiVqDOYfaGhw1/Bf/wXHlwAXGLGyTbSNgj4HMcNMIa6Dh0cg2iplzj5xhYikL9PB1Or9r+I10aXgyEu24F+cgUdWA==; 5:9e9BaDvcBY6oOuqhr+YJAT4TlZCBjGo6gd2b7TFfu6tJO9QzBrjA6MOeTRVy/2XvBs56mDCvr2iB3T0s2fed+dOpbxyCKK2Z2iAgyH6hZRjorBgWApfqZ0wyWwT/nAQehaSC8kX1JDCWYaACXQVFYv1GSEU5wxCNEj8q/+MB22g=; 7:WnkX/o3eQ3C8+s06bGkXYBcKxSEoAtv9/07DmV4ReTPG6NiYyhggfLffaz2qSklT3DFp3vHc6smbDssG1NNjSzwGSqrvimN87ymdmxTH1H/eQfCRfw1ofjhaAw6gHEE7IfalbmNpn9/eA7lgLMqlaw==
x-ms-office365-filtering-correlation-id: 7d51b9c8-6cab-4faa-8376-08d6554ee742
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:DM5PR0501MB3816;
x-ms-traffictypediagnostic: DM5PR0501MB3816:
x-microsoft-antispam-prvs: <DM5PR0501MB38162CE44EF33973F117C863D4D10@DM5PR0501MB3816.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)(3231443)(999002)(944501410)(52105112)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DM5PR0501MB3816; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0501MB3816;
x-forefront-prvs: 0870212862
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(136003)(366004)(396003)(346002)(78114003)(199004)(189003)(86362001)(478600001)(54906003)(2906002)(5024004)(14444005)(256004)(31686004)(6916009)(6246003)(31696002)(53546011)(305945005)(6512007)(446003)(102836004)(6436002)(2616005)(76176011)(386003)(486006)(6506007)(11346002)(316002)(476003)(52116002)(105586002)(224303003)(186003)(224313004)(26005)(229853002)(106356001)(53936002)(4326008)(71190400001)(6486002)(99286004)(66574009)(36756003)(81156014)(25786009)(68736007)(71200400001)(3846002)(6116002)(97736004)(5660300001)(14454004)(66066001)(7736002)(8936002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0501MB3816; 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: UVQhxKZJQfizoISgBHJg2SU2OGERfV29VQ4cyuGuAziT1QqPESvZ5bkp6948CrFT3mwbJ2iglYRGjWtzvNU5YhFOA+TFxYtxjKQu5RWdn73f+pIuTIV8P97GTUJ6+b59AcegZRfkFsJYTF7cpoCwgkFTdP6itUdrLzLb8xYK4RjRAXqQ4UFuXlkRA8u0edOJH1Y27f8bTSpQsHNqbawkbfh4jAiPjvAtR0ZJUL65ynkBm/ZVlCIscxNn9CoHrhFV0vp5hl7USMXVoXIVezFeANceERP8d64OErZmyHjqjBUU7pUMW+4iuPAQtpfiz9+qiVTrpIMUhmMLdB/mZxGApXjTpOX9IL4PK7jg6i3RNGw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <57240579D5674649827D64CCCF1E4B2F@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 7d51b9c8-6cab-4faa-8376-08d6554ee742
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2018 16:31:09.8722 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3816
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-28_08:, , 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=1015 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-1811280144
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/KJS30hQKsMKQSdybwEyHbnrfYyg>
Subject: Re: [bess] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?bess-mvpn-expl-track-12=3A_=28with_DISCUSS_and_COMMENT=29?=
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: Wed, 28 Nov 2018 17:15:18 -0000

Mirja,

I believe draft-ietf-bess-mvpn-expl-track-13 addresses your issues. I 
have expanded the Security Considerations section per your suggestions, 
which IMO are all very reasonable.

Please let me know whether this is satisfactory.

Thanks.

Eric

On 11/26/2018 9:03 AM, Mirja Kuehlewind (IETF) wrote:
> Hi Eric,
>
> thanks for your detailed reply. Please see below.
>
>> Am 15.11.2018 um 19:07 schrieb Eric Rosen <erosen@juniper.net>et>:
>>
>> 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.
> Okay, then I would simply suggest to say this ("Properly protecting the control plane should prevent this kind of attack“) instead of just calling it out of scope.
>
>> 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.
> This suggest that there is no good counter measure which would be more appropriate  to say instead of calling it out of scope. I think it could even be helpful to add some of your explanation above to the security consideration section (instead of leaving this as an exercise to the reader).
>
>> 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.
> I think this would be a good recommendation. I guess it actually does have to be a MUST, or you could say something like MUST be logged by default but can be configured differently if the protection mechanism used for the control plan is monitored. As I said, I’m really no expert here and you need to decide if that makes any sense though.
>
> Mirja
>
>
>> 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.