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

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Mar 2018 08:26:06 +0000

Thanks for updating the security considerations. I have two concerns about
the following section:

   It is assumed that both BIER and OSPF layer is under a single
   administrative domain.  There can be deployments where potential
   attackers have access to one or more networks in the OSPF routing
   domain.  In these deployments, stronger authentication mechanisms
   such as those specified in [RFC7474] SHOULD be used.

First, why are you assuming that BIER will be run within a single
administrative domain. That's not generally the case for multicast
now, is it? Or is it merely that OSPF will generally be run within
a single administrative domain and if you are to run BIER outside
a single administrative domain you won't want to use OSPF? It's
hard to tell from the BIER security considerations how severe
the situation is if routing is subverted, but given the uses to
which multicast is put, it seems like it could result in some
fairly large volumes of diverted traffic.

Second, even within an administrative domain, it's not safe to assume
that the links are in fact safe, so generally one would expect that
you would run communications security on at the routing protocol to
ensure integrity. It seems like there are two ways to look at this:

1. We are just extending OSPF to do a new thing, so the previous
   (weak) standards apply.

2. We are basically designing routing for an entirely new kind of
   thing (BIER), even though it happens to use OSPF, so modern
   standards should apply.

At present, I lean towards the second interpretation, especially, but
I'd like to hear what the other members of the IESG think, especially
my security co-ADs.

-Ekr

On Wed, Feb 21, 2018 at 5:24 PM, Eric Rescorla <[email-masked]> wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-bier-ospf-bier-extensions-13: 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-bier-ospf-bier-extensions/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Document: draft-ietf-bier-ospf-bier-extensions-12.txt
>
> I have not yet reviewed this document in detail:
>
>    Implementations must assure that malformed TLV and Sub-TLV
>    permutations do not result in errors which cause hard OSPF failures.
>
> This is not an adequate security considerations section. What is your
> threat model? What attacks are possible? What are not? It may be the
> case that this is all covered in other documents, and you just need to
> point to them, but the reader doesn't know that, so this needs to be
> documented. Adam Montville's SECDIR review which makes some of the
> same points and lists a few specific items to examine.
>
>
>
>
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 15 Mar 2018 10:24:30 -0400

Hi Eric,

> fairly large volumes of diverted traffic.

Practical deployments of multicast are in single forwarding domains today.
If there is desire to support multicast between administrative domains, it
would
likely extend BGP for the inter-domain interactions.  OSPF is an IGP which
is
always a single administrative domain.  It has complete shared trust in the
distributed routing database to support the distributed SPF computation.

> ensure integrity. It seems like there are two ways to look at this:

I believe that RFC 7474 is providing an authentication mechanism that
provides
integrity-protection and prevents against replay.  It isn't private - but
untrusted
links for listening are very different than being able to inject packets.
Regardless,
RFC 7474 provides that protection.

One of the challenges with routing protocols is the bootstrapping aspects
of some
of the general security mechanisms, that depend on having network
connectivity
to reach resources that simply isn't available before routing is
functional.

>    thing (BIER), even though it happens to use OSPF, so modern

I personally do not know what more would be desired practically for OSPF
security.
Acee, of course, will have more focused opinions - but it isn't clear to me
what would
be desirable to add.  I think KARP dealt with OSPF as practically as
possible.

As for "should modern standards apply" - it's a mixture and depends on what
types
of attacks are truly of concern. Deborah has taken up looking for a Design
Team to
try to better articulate what is there for security and the trade-offs.

BIER is based on MPLS and Ethernet.  For Ethernet, there is the existence
of MAC
Security.  For MPLS, there have been no market motivators for having
hop-by-hop
encryption; for example, a draft describing how to do this sat adopted in
the MPLS WG
for several years - but could not find anyone interested in even
implementing it for
experimental.

When one examines the data in the BIER header, it is fundamentally expected
to
change at every hop and is network data.  The user-data in the packets,
can, of course
be protected by the end-to-end applications.

Regards,
Alia

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

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 15 Mar 2018 08:09:30 -0700

On Thu, Mar 15, 2018 at 1:26 AM, Eric Rescorla <[email-masked]> wrote:

> a single administrative domain you won't want to use OSPF?
>

Eric,

OSPF is normally run within a single AD (at least I never saw it stretching
ADs unless we talk about DMZ as such a thing
or consider overlays running OSPF though
the overlays are their own ADs) due to the way the protocol is designed.
In fact, it does not carry AS as a concept anywhere (modulo some
corner-cases
such as 4577 where AS is encoded in tags), instead it talks about
ASBR which is the AS border OSPF touches (and where AS
external routes can be injected). So I don't think any inter-AS
considerations for this draft are relevant as they may have to in
IDR extensions.

> It's
>    standards should apply

> I'd like to hear what the other members of the IESG think, especially

I would be interested why you lean towards the 2nd interpretation.
In my view, BIER is a very lightweight addition on top of OSPF and does not
extend any of its primitives at all except using the standard way to
add some sub-TLVs using RFC7684 and RFC4915, both long
established OSPF concepts. In a sense it uses OSPF as
light-weight signalling only (and currently uses its computation results
to derive a set of BIER next-hops). Neither represents any
change in OSPF architecture or threat model IMO.

If your concern is addressing what you describe as "weak" standard
OSPF security then I would venture to say that trying to put that into a
BIER OSPF signalling draft would be a poor choice of locus.  Same for
BIER as forwarding plane/architecture security considerations.

So, if we have to spell out that BIER OSPF signalling has the same
security profile as OSPF, yes, a good reference "boilerplate" would be nice
and
same for BIER as forwarding paradigm/architecture.

thanks

-- tony

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 15 Mar 2018 13:44:25 -0400

EKR raises a few interesting issues; let me throw in my two cents.

On 3/15/2018 4:26 AM, Eric Rescorla wrote:
> administrative domain.

BIER requires each BFR to be assigned a BFR-id, which is  a 16-bit 
number.  Since the BFR-ids are not globally unique, a particular 
assignment of BFR-id to BFR is constrained to a single "administrative 
domain" of some sort.  What BIER really does is to simplify the 
multicast data and control planes within the bounds of an administrative 
domain.

> That's not generally the case for multicast
> now, is it?

Actually, it is.  At least in practice.

> Or is it merely that OSPF will generally be run within

The BIER extensions to OSPF provide the information needed to run BIER 
within the OSPF administrative domain.

> the situation is if routing is subverted,

If the OSPF routing can be subverted, there is no limit to the amount of 
damage that can be done to both unicast and multicast traffic.  You 
could, e.g., divert all unicast traffic that has certain destination 
addresses.  One has to remember that, with BIER, the path taken by a 
multicast packet to get from A to B is generally the same as the path 
taken by a unicast packet to get from A to B. Screw up the latter and 
you screw up the former.

> but given the uses to

Since BIER depends upon the soundness of the unicast routing, an attack 
on the unicast routing could be used to screw up the multicast traffic.  
If the unicast routing is not protected, there is hardly any point in 
protecting the OSPF BIER extensions.  That would be like leaving your 
front door open and then being careful to lock your kitchen window.

> that the links are in fact safe,

Link layer security has been available for a long time.

> so generally one would expect that
> ensure integrity.

  For an IGP, I'd think that you really want authentication to make sure 
that every participant in the IGP is actually one of the routers that 
belongs to the proper administration.

> It seems like there are two ways to look at this:
>
> At present, I lean towards the second interpretation,

One has to remember that BIER depends upon the unicast routing that is 
established by OSPF.  It's not just that the OSPF packets have been 
extended to carry BIER-specific information; the BIER traffic follows 
paths that are computed by the (unicast) SPF algorithm from the 
(unicast) topology information distributed by OSPF.

So I think the proper conclusion is that better security for the IGPs 
would benefit BIER, but authentication/integrity/privacy for just the 
BIER-specific information carried by OSPF does not really provide 
anything worthwhile.

> especially, but

Even better would be to hear practical solutions to the routing security 
problems!

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 15 Mar 2018 18:02:33 +0000

Hi Eric,

I agree with Tony and Alia that OSPF is defined within a single administrative domain – the “I” in “IGP” is for “Internal”. In some deployments, the BIER information may be exported between protocols and domains. However, this would all more into the realm of IDR.

With respect to OSPF Security, I don’t know why using OSPF for discovery of BIER parameters requires any more or less security than the underlay over which the multicast forwarding is deployed. I agree that the exposures are different (as Peter conveyed in the updated text). I see a reference to (weak) OSPF security below. Rather than levying tangential DISCUSS’es on LSR documents advertising additional information, perhaps a better tact would be to define precisely what you think is weak about OSPF (and IS-IS) security and take it to the LSR WG as requirements. I agree it would be good to consolidate generic OSPF (and IS-IS) security considerations into new document(s) but I’m not sure that we need new mechanism. Please clear this DISCUSS ASAP.

Thanks,
Acee

From: Alia Atlas <[email-masked]>
Date: Thursday, March 15, 2018 at 10:24 AM
To: Eric Rescorla <[email-masked]>, Acee Lindem <[email-masked]>
Cc: The IESG <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>, BIER WG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bier] Eric Rescorla's Discuss on draft-ietf-bier-ospf-bier-extensions-13: (with DISCUSS)

Hi Eric,

On Thu, Mar 15, 2018 at 4:26 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for updating the security considerations. I have two concerns about
the following section:

Practical deployments of multicast are in single forwarding domains today.
If there is desire to support multicast between administrative domains, it would
likely extend BGP for the inter-domain interactions.  OSPF is an IGP which is
always a single administrative domain.  It has complete shared trust in the
distributed routing database to support the distributed SPF computation.

I believe that RFC 7474 is providing an authentication mechanism that provides
integrity-protection and prevents against replay.  It isn't private - but untrusted
links for listening are very different than being able to inject packets.  Regardless,
RFC 7474 provides that protection.

One of the challenges with routing protocols is the bootstrapping aspects of some
of the general security mechanisms, that depend on having network connectivity
to reach resources that simply isn't available before routing is functional.

I personally do not know what more would be desired practically for OSPF security.
Acee, of course, will have more focused opinions - but it isn't clear to me what would
be desirable to add.  I think KARP dealt with OSPF as practically as possible.

As for "should modern standards apply" - it's a mixture and depends on what types
of attacks are truly of concern. Deborah has taken up looking for a Design Team to
try to better articulate what is there for security and the trade-offs.

BIER is based on MPLS and Ethernet.  For Ethernet, there is the existence of MAC
Security.  For MPLS, there have been no market motivators for having hop-by-hop
encryption; for example, a draft describing how to do this sat adopted in the MPLS WG
for several years - but could not find anyone interested in even implementing it for
experimental.

When one examines the data in the BIER header, it is fundamentally expected to
change at every hop and is network data.  The user-data in the packets, can, of course
be protected by the end-to-end applications.

Regards,
Alia

-Ekr

On Wed, Feb 21, 2018 at 5:24 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Eric Rescorla has entered the following ballot position for
draft-ietf-bier-ospf-bier-extensions-13: Discuss

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

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 15 Mar 2018 11:13:49 -0700

Eric,

I support Acee’ and Alia’ comments specifically wrt BIER extensions to IGPs and would like this discussion to lead to IGP security consideration discussion in LSR , rather than to “overloading” BIER.

Cheers,

Jeff

From: BIER <[email-masked]> on behalf of "Acee Lindem (acee)" <[email-masked]>
Date: Thursday, March 15, 2018 at 11:02
To: Alia Atlas <[email-masked]>, Eric Rescorla <[email-masked]>
Cc: "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)

Hi Eric,

Thanks,

Acee

Hi Eric, 

the following section:

   (weak) standards apply.

   standards should apply.

experimental.

Regards,

Alia

my security co-ADs.

-Ekr

 

 

 

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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Mar 2018 18:31:56 +0000

> considerations for this draft are relevant as they may have to in

Thanks. This makes the situation somewhat better, though if the
routing traffic traverses insecure links, then there is still a risk.

> change in OSPF architecture or threat model IMO.

I agree that from an OSPF perspective, the changes are trivial,
but that's not the question. As I understand BIER, the traffic
pattern is significantly different from conventional unicast routing
and therefore it's at minimum important to determine whether
what we considered acceptable -- though regrettable -- properties
of the routing system are in fact acceptable with BIER as well.

I don't see any analysis of this in the document, or in the BIER
architecture document. Is there some?

> BIER as forwarding plane/architecture security considerations.

What's weak here is that the document doesn't require that one *use* 7474,
even in settings where the document acknowledges that it's insecure not
to:

As I said, that's not ideal, but it's the state we're in.

-Ekr

> security profile as OSPF, yes, a good reference "boilerplate" would be
> nice and

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Mar 2018 18:35:01 +0000

> RFC 7474 provides that protection.

I agree that 7474 would be adequate. My concern whether the weak requirement
for it (in general not at all and only SHOULD-level even when the OSPF
traffic
crosses admin domains) is adequate for the kind of traffic that is being
routed
here.

> be protected by the end-to-end applications.

Agreed. Without studying it in detail, this initially seems like a
reasonable answer for BIER
itself.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Mar 2018 18:41:01 +0000

I've already sent a few messages, so I'll skip to what I think is the main
point

On Thu, Mar 15, 2018 at 5:44 PM, Eric C Rosen <[email-masked]> wrote:
> damage that can be done to both unicast and multicast traffic.  You could,
> e.g., divert all unicast traffic that has certain destination addresses.
> One has to remember that, with BIER, the path taken by a multicast packet
> to get from A to B is generally the same as the path taken by a unicast
> packet to get from A to B. Screw up the latter and you screw up the former.

Perhaps this is where I am getting confused. 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?)

-Ekr

> Since BIER depends upon the soundness of the unicast routing, an attack on
> the unicast routing could be used to screw up the multicast traffic.  If
> the unicast routing is not protected, there is hardly any point in
> protecting the OSPF BIER extensions.  That would be like leaving your front
> door open and then being careful to lock your kitchen window.
>
>
> extended to carry BIER-specific information; the BIER traffic follows paths
> that are computed by the (unicast) SPF algorithm from the (unicast)
> topology information distributed by OSPF.
>
> BIER-specific information carried by OSPF does not really provide anything
> worthwhile.
>
> especially, but

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 15 Mar 2018 14:58:56 -0400

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 

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: Eric Rescorla <[email-masked]>
Date: Tue, 20 Mar 2018 21:48:42 +0000

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:

>> 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?)
>>
>
> 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.
>
> 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.
>
> packet and forward multiple copies.  However, a given bit will only be set
> in one copy of the packet.
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 20 Mar 2018 23:22:06 +0000

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.

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 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]<mailto:[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: Eric Rescorla <[email-masked]>
Date: Tue, 20 Mar 2018 23:28:16 +0000

On Tue, Mar 20, 2018 at 11:22 PM, Les Ginsberg (ginsberg) <
[email-masked]> wrote:

> 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)
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 21 Mar 2018 05:48:48 +0000

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.

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.
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]<mailto:[email-masked]>> wrote:
Eric –

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]<mailto:[email-masked]>> On Behalf Of Eric Rescorla
Sent: Tuesday, March 20, 2018 2:49 PM
To: Eric C Rosen <[email-masked]<mailto:[email-masked]>>
Cc: Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BIER WG <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Bier] Eric Rescorla's Discuss on draft-ietf-bier-ospf-bier-extensions-13: (with DISCUSS)

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Mar 2018 06:24:28 +0000

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

> *“One could cause an amplification attack by modifying the data packet's
> 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
> 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
> 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].”*
>
>
>
> *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]
>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 21 Mar 2018 12:06:34 +0000

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]<mailto:[email-masked]>> wrote:
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.

-Ekr

    Les

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

-Ekr

Thanx.

   Les

-Ekr

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 30 Mar 2018 22:21:48 +0000

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

Sent: Tuesday, March 20, 2018 11:24 PM

-Ekr

    Les

-Ekr

Thanx.

   Les

-Ekr