Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
Thanks you very much! Just cleared my discuss!
> Am 28.11.2018 um 17:31 schrieb Eric Rosen :
>
> 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 :
>>>
>>> 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
Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
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 :
>>
>> 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
Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
Hi Eric,
thanks for your detailed reply. Please see below.
> Am 15.11.2018 um 19:07 schrieb Eric Rosen :
>
> 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.
Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
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“/ >
Re: [bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
Hi! Protecting the control plane is a topic that is wider than this document…or even wider than “just for BGP” (as covered by rfc7454). Additional recommendations are given in both rfc7454 and rfc6192 — this document should then have a reference to them. My 2c. Alvaro. On October 24, 2018 at 5:28:55 AM, Mirja Kühlewind (i...@kuehlewind.net) 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! ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] Mirja Kühlewind's Discuss on draft-ietf-bess-mvpn-expl-track-12: (with DISCUSS and COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-bess-mvpn-expl-track-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-expl-track/ -- 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! -- 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.“..? 2) section 3 s/The result (if any) is the match for tracking“/The result (if any) is the “match for tracking“/ (missing quotes) ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
