Subject: Re: [Bier] Eric Rescorla's Discuss on draft-ietf-bier-ospf-bier-extensions-13: (with DISCUSS)

From: Eric Rescorla <[email-masked]>
Date: Sun, 1 Apr 2018 11:19:00 -0700

Thank you. I have cleared my DISCUSS

On Fri, Mar 30, 2018 at 3:21 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> Eric –
>
>
>
> V11 of the IS-IS draft has been posted which we believe addresses your
> concerns regarding the Security section.
>
> If you agree, please clear your DISCUSS.
>
> If not, please let us know why.
>
>
>
> Thanx.
>
>
>
>    Les
>
>
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Tuesday, March 20, 2018 11:24 PM
>
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Eric C Rosen <[email-masked]>; Reshad Rahman (rrahman) <
> [email-masked]>; [email-masked]; BIER WG <[email-masked]>; The
> IESG <[email-masked]>; [email-masked]
> *Subject:* Re: [Bier] Eric Rescorla's Discuss on
> draft-ietf-bier-ospf-bier-extensions-13: (with DISCUSS)
>
>
>
>
>
>
>
> On Wed, Mar 21, 2018 at 5:48 AM, Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Eric –
>
>
>
> What Eric Rosen said was (some emphasis added):
>
>
>
> *“One could cause an amplification attack by modifying the data packet's
> in-flight.  Or one could compromise an ingress BFR (BFIR) and set all the
> bits in the BIER BitString.  These attacks are mentioned in the Security
> Considerations section of RFC 8279.*
>
>
>
> *However, I don't think there is anything one can do to the OSPF or ISIS
> control messages that would cause an amplification attack.*
>
>
>
> *The BFIR decides which hosts are to receive a packet.  In making this
> decision, it is not influenced by the IGP control messages. When creating
> the encapsulation, the BFIR sets one bit in the encapsulation for each
> destination host.  The information in the OSPF/ISIS extensions is used to
> construct the forwarding tables that map each bit in the encapsulation into
> a set of next hops for the host that is identified by that bit.*
>
>
>
> *If a BFR receives a packet with n bits set, it may have to replicate the
> packet and forward multiple copies.  However, a given bit will only be set
> in one copy of the packet.*
>
>
>
> *So I don't see how one could mount an amplification attack by modifying
> the OSPF/ISIS messages.”*
>
>
>
> If (as you suggest below) you are not satisfied with the discussion in RFC
> 8279 then the proper thing to do is to suggest an update to RFC 8279 – not
> to insert a discussion of BIER security issues into the IGP drafts.
>
>
>
> Sorry, I also don't agree with this. BIER provides a mechanism for the
> routing of the multicast packets but not for setting up the topology. It
> leaves open how that topology is set up. These documents describe how to
> set up that topology and permit that topology to be set up in a way that is
> subject to attack by on-path attackers. The discussion of the security
> impact of that decision is therefore properly in these documents.
>
>
>
> -Ekr
>
>
>
>
>
>
>
> Note that the BIER IS-IS draft already includes the statement:
>
>
>
> *“BIER specific security considerations are discussed in [RFC8279].”*
>
>
>
> I would suggest that the same statement be added to the BIER OSPF draft.
>
>
>
>     Les
>
>
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Tuesday, March 20, 2018 4:28 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Eric C Rosen <[email-masked]>; Reshad Rahman (rrahman) <
> [email-masked]>; [email-masked]; BIER WG <[email-masked]>; The
> IESG <[email-masked]>; [email-masked]
>
>
> *Subject:* Re: [Bier] Eric Rescorla's Discuss on
> draft-ietf-bier-ospf-bier-extensions-13: (with DISCUSS)
>
>
>
>
>
>
>
> On Tue, Mar 20, 2018 at 11:22 PM, Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
> Eric –
>
>
>
> (Speaking as author of BIER IS-IS draft – which I assume would require
> equivalent changes)
>
> I appreciate the careful review you have done – and the meaningful
> discussion you and Eric Rosen have had.
>
>
>
> If we spent our lives recording everything which is “NOT a risk” in every
> draft we would have much less available time and much longer and less
> readable drafts.
>
>
>
> The purpose of the Security Considerations section is to accurately
> document the security properties of the system. This includes attacks that
> it protects against.
>
>
>
>
>
> If you are satisfied with the Security discussion in the BIER architecture
> drafts I propose we leave it at that and allow the BIER IGP drafts to
> proceed as is.
>
>
>
> I didn't say I was satisfied with them. I said that between the drafts and
> Eric's explanation I was convinced this wasn't a problem. But other people
> will not have the benefit of that interaction. For that reason, and given
> that we know people will run the IGP in an unauthenticated mode, I think
> it's important to document what the consequences of compromise of the IGP
> are. Something like Eric's note should suffice.
>
>
>
> -Ekr
>
>
>
> I believe they have accurately captured what are the security issues
> associated with the IGP BIER extensions and I believe the BIER architecture
> RFCs have done a good job detailing the security issues associated with
> BIER itself. I believe that is exactly what is appropriate and what is
> needed.
>
>
>
> Thanx.
>
>
>
>    Les
>
>
>
>
>
> *From:* BIER <[email-masked]> *On Behalf Of *Eric Rescorla
> *Sent:* Tuesday, March 20, 2018 2:49 PM
> *To:* Eric C Rosen <[email-masked]>
> *Cc:* Reshad Rahman (rrahman) <[email-masked]>; [email-masked];
> BIER WG <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]
> *Subject:* Re: [Bier] Eric Rescorla's Discuss on
> draft-ietf-bier-ospf-bier-extensions-13: (with DISCUSS)
>
>
>
> Thanks. Based on this and a review of the BIER architecture I agree with
> this assessment.
>
>
>
> I think some text to this effect would be useful in the specification so
> it's clear why the risk is low. Would it be a problem to add some?
>
>
>
> -Ekr
>
>
>
>
>
> On Thu, Mar 15, 2018 at 6:58 PM, Eric C Rosen <[email-masked]> wrote:
>
> On 3/15/2018 2:41 PM, Eric Rescorla wrote:
>
> Because this is multicast, what I'm concerned with is whether it's
> possible to manipulate the routing fabric to mount a serious amplification
> attack. E.g., to cause a set of packets which should only have been sent to
> a small number of hosts to be amplified and sent to a large number of
> hosts. This seems like would be qualitatively different from just rerouting
> unicast traffic. Is this possible (assuming that the routing layer is not
> secured?)
>
>
> One could cause an amplification attack by modifying the data packet's
> in-flight.  Or one could compromise an ingress BFR (BFIR) and set all the
> bits in the BIER BitString.  These attacks are mentioned in the Security
> Considerations section of RFC 8279.
>
> However, I don't think there is anything one can do to the OSPF or ISIS
> control messages that would cause an amplification attack.
>
> The BFIR decides which hosts are to receive a packet.  In making this
> decision, it is not influenced by the IGP control messages. When creating
> the encapsulation, the BFIR sets one bit in the encapsulation for each
> destination host.  The information in the OSPF/ISIS extensions is used to
> construct the forwarding tables that map each bit in the encapsulation into
> a set of next hops for the host that is identified by that bit.
>
> If a BFR receives a packet with n bits set, it may have to replicate the
> packet and forward multiple copies.  However, a given bit will only be set
> in one copy of the packet.
>
> So I don't see how one could mount an amplification attack by modifying
> the OSPF/ISIS messages.
>
>
>
>
>
>
>

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 6 Apr 2018 05:49:18 -0400

Nagendra/Eric:

Hi!

Where are we on this document?  It looks like this was the last
OSPF-related message in the thread (the next two were about the ISIS
version).

An update (-17) was posted after this message with changes to the Security
Considerations [1].  Does that address the open issues?

Thanks!

Alvaro.

[1]
https://www.ietf.org/rfcdiff?url1=draft-ietf-bier-ospf-bier-extensions-16&url2=draft-ietf-bier-ospf-bier-extensions-17

On March 21, 2018 at 1:06:43 PM, Nagendra Kumar Nainar (naikumar) (
[email-masked]) wrote:

Hi Eric Rescorla,

<Eric> Sorry, I also don't agree with this. BIER provides a mechanism for
the routing of the multicast packets but not for setting up the topology.
It leaves open how that topology is set up. These documents describe how to
set up that topology and permit that topology to be set up in a way that is
subject to attack by on-path attackers. The discussion of the security
impact of that decision is therefore properly in these documents.

<Nagendra> BIER OSPF extensions leverages the existing topology setup
mechanism and advertises additional details for BIER forwarding. OSPF
extensions does not control or map the receivers to each multicast stream.
This document does not define any changes in SPF computation and follow the
unicast path to the relevant prefixes associated with BFR-ID.

I think, compromising the extension defined in this draft may need one to
modify domain/topology/BFR ID, algorithms or the label. In any of these
cases, I think the packet will result in black holing. I don’t think
compromising any of these fields will result in populating the forwarding
table to rewrite the header with additional bits which I think is required
for amplification attack.

Thanks,

Nagendra

*From: *Eric Rescorla <[email-masked]>
*Date: *Wednesday, March 21, 2018 at 2:25 AM
*To: *"Les Ginsberg (ginsberg)" <[email-masked]>
*Cc: *Eric C Rosen <[email-masked]>, "Reshad Rahman (rrahman)" <
[email-masked]>, "[email-masked]" <[email-masked]>, BIER WG <
[email-masked]>, The IESG <[email-masked]>, "
[email-masked]" <
[email-masked]>
*Subject: *Re: [Bier] Eric Rescorla's Discuss on
draft-ietf-bier-ospf-bier-extensions-13: (with DISCUSS)
*Resent-From: *<[email-masked]>
*Resent-To: *<[email-masked]>, Nagendra Kumar Nainar <[email-masked]>,
IJsbrand Wijnands <[email-masked]>, <[email-masked]>, <
[email-masked]>, <[email-masked]>, <[email-masked]>
*Resent-Date: *Wednesday, March 21, 2018 at 2:25 AM

On Wed, Mar 21, 2018 at 5:48 AM, Les Ginsberg (ginsberg) <[email-masked]>
wrote:

Eric –

-Ekr

    Les

*From:* Eric Rescorla <[email-masked]>
*Sent:* Tuesday, March 20, 2018 4:28 PM
*To:* Les Ginsberg (ginsberg) <[email-masked]>
*Cc:* Eric C Rosen <[email-masked]>; Reshad Rahman (rrahman) <
[email-masked]>; [email-masked]; BIER WG <[email-masked]>; The IESG
<[email-masked]>; [email-masked]

Eric –

-Ekr

Thanx.

   Les

-Ekr

Because this is multicast, what I'm concerned with is whether it's possible
to manipulate the routing fabric to mount a serious amplification attack.
E.g., to cause a set of packets which should only have been sent to a small
number of hosts to be amplified and sent to a large number of hosts. This
seems like would be qualitatively different from just rerouting unicast
traffic. Is this possible (assuming that the routing layer is not secured?)

So I don't see how one could mount an amplification attack by modifying the
OSPF/ISIS messages.

_______________________________________________
BIER mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bier