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

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 <bier-bounces@ietf.org> on behalf of "Acee Lindem (acee)" <acee@cisco.com>
Date: Thursday, March 15, 2018 at 11:02
To: Alia Atlas <akatlas@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "bier-chairs@ietf.org" <bier-chairs@ietf.org>, BIER WG <bier@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-bier-ospf-bier-extensions@ietf.org" <draft-ietf-bier-ospf-bier-extensions@ietf.org>
Subject: Re: [Bier] Eric Rescorla's Discuss on draft-ietf-bier-ospf-bier-extensions-13: (with DISCUSS)

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 <akatlas@gmail.com>
Date: Thursday, March 15, 2018 at 10:24 AM
To: Eric Rescorla <ekr@rtfm.com>, Acee Lindem <acee@cisco.com>
Cc: The IESG <iesg@ietf.org>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, BIER WG <bier@ietf.org>, "draft-ietf-bier-ospf-bier-extensions@ietf.org" <draft-ietf-bier-ospf-bier-extensions@ietf.org>, "bier-chairs@ietf.org" <bier-chairs@ietf.org>
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 <ekr@rtfm.com> wrote:

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.

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. 

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:

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.  

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.

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

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 <ekr@rtfm.com> 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.

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier

_______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier 