Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <8de86550-39cd-8c4c-75ba-8e7a033fc907@juniper.net>
Date: Mon, 26 Nov 2018 15:03:34 +0100
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B680F2EC-7F28-4CC5-ABE6-4547B4BDD028@kuehlewind.net>
References: <154038410206.6927.15775732681687781010.idtracker@ietfa.amsl.com>
 <8de86550-39cd-8c4c-75ba-8e7a033fc907@juniper.net>
To: Eric Rosen <erosen@juniper.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/frjZlhNLtBLftjiVhwSy8F2cark>
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?=
Precedence: list

Hi Eric,

thanks for your detailed reply. Please see below.

> Am 15.11.2018 um 19:07 schrieb Eric Rosen <erosen@juniper.net>:
>=20
> On 10/24/2018 8:28 AM, Mirja K=C3=BChlewind wrote:
>> ---------------------------------------------------------------------
>> DISCUSS:
>> =
----------------------------------------------------------------------
>>=20
>> In section 9 (security considerations):
>> Thanks for discussing network load here! However, I find this =
sentence a bit
>> unsatisfactory:
>>    =E2=80=9EThe specification of counter-measures for this problem is =
outside the scope
>>    of this document.=E2=80=9C
>> Isn=E2=80=99t 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=E2=80=99m not an expert on =
this topic and
>> therefore don=E2=80=99t 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=E2=80=99s current said. Thanks!
>=20
> These particular suggestions don't really work in this context.
>=20
> - The set of Provider Edge routers (PEs) that attach to a given VPN is=20=

> always auto-discovered, never pre-configured.  That's an important =
part=20
> of the L3VPN value proposition.   There are already mechanisms in =
place=20
> to ensure that the S-PMSI A-D route gets sent only to the proper set =
of=20
> egress PEs.  Also, a properly functioning egress PE will only respond=20=

> with a Leaf A-D route if it has already auto-discovered the ingress =
PE. =20
> (You might want to question the security of the L3VPN mechanisms, but=20=

> that would certainly be outside the scope of this document .)
>=20
> - Rate limiting the generation of Leaf A-D routes wouldn't work, =
because=20
> the problem is not that one PE generates too many, but that too many =
PEs=20
> may generate them.  Rate limiting the processing of received Leaf A-D=20=

> routes is also problematic.  In normal operation, you might correctly=20=

> get a whole bunch of them in quick succession, and if you don't =
process=20
> them in a timely manner, the customers will see a high multicast "join=20=

> latency".
>=20
> In the particular sort of attack mentioned in the Security=20
> Considerations section, an ingress PE originates an S-PMSI A-D route=20=

> with LIR-pF clear, but somehow the bit gets set before the route is=20
> received by the egress PEs.   As Alvaro has suggested, if an attacker=20=

> can modify the control messages, quite a bit of havoc can result, and=20=

> the particular attack under discussion is just one of many that can=20
> occur if the control plane is not secure.  I can certainly put in a=20
> reference to RFCS 6192 and 7454 (as Alvaro suggests), if you think =
that=20
> is helpful.  Properly protecting the control plane should prevent this=20=

> kind of attack.

Okay, then I would simply suggest to say this ("Properly protecting the =
control plane should prevent this kind of attack=E2=80=9C) instead of =
just calling it out of scope.

>=20
> In the event such an attack occurs, mitigating it is unfortunately not=20=

> very straightforward.  The ingress node can take note of the fact that=20=

> it is getting Leaf A-D routes with LIR-pF set, in response to an =
S-PMSI=20
> A-D route with LIR-pF clear.  Withdrawing the S-PMSI A-D route could =
put=20
> a stop to the attack.  However, there are a few problems with this:
>=20
> - Under normal operation, there are some race conditions that may =
cause=20
> the ingress node to think it is being attacked, when in fact it is =
not.
>=20
> - If some egress nodes have a bug that causes them to set LIR-pF when =
it=20
> should be clear, withdrawing the S-PMSI A-D route will stop the flow =
of=20
> multicast data traffic to all the egress nodes, causing an unnecessary=20=

> customer-visible disruption.
>=20
> - The same situation that caused the S-PMSI A-D route to be originated=20=

> in the first place will still exist after the S-PMSI A-D route is=20
> withdrawn, so the route will just be re-originated.
>=20
> In other words, any action that would ameliorate the effects of this=20=

> sort of attack would have a negative effect during normal operation. =20=

> Therefore it is really better to rely on security mechanisms that=20
> protect the control plane generally, rather than having a mechanism =
that=20
> 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).

>=20
> We could say that if an ingress PE receives a Leaf A-D route with =
LIR-pF=20
> set, and that route is a response to an S-PMSI A-D route that did not=20=

> have LIR-pF set, the event MUST be logged.  This would generate some=20=

> noise in the log during normal operation, but could provide at least a=20=

> 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=E2=80=99m really no =
expert here and you need to decide if that makes any sense though.

Mirja


>=20
> What do you think?
>=20
>> =
----------------------------------------------------------------------
>> COMMENT:
>> =
----------------------------------------------------------------------
>>=20
>> Some other minor comments:
>>  1) section 2: =E2=80=9EUse 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.=E2=80=9C
>> Maybe you also want to say something like =E2=80=9EThe flag SHOULD be =
ignored in these cases.=E2=80=9C..?
>=20
> Agreed.
>=20
>>=20
>>  2) section 3
>> s/The result (if any) is the match for tracking=E2=80=9C/The result =
(if any) is the =E2=80=9Cmatch for tracking=E2=80=9C/
>> (missing quotes)
>=20
> Fixed in the next revision.