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

[Eric Rescorla <[e-mail]>]

On Thu, Mar 15, 2018 at 3:09 PM, Tony Przygienda <[e-mail]>
wrote:

>
>
> On Thu, Mar 15, 2018 at 1:26 AM, Eric Rescorla <[e-mail]> 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?
>>
>
> 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.
>

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


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

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?


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

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:

   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.

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

-Ekr


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
>
>
>
>
>>
>> -Ekr
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 21, 2018 at 5:24 PM, Eric Rescorla <[e-mail]> 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/stat
>>> ement/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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bier
>>
>>
>