Subject: [Bier] Alvaro Retana's No Objection on draft-ietf-bier-ospf-bier-extensions-14: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Thu, 22 Feb 2018 06:25:39 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-bier-ospf-bier-extensions-14: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) The specification of the sub-TLVs still needs some work:

- MT-ID: What should a receiver do if the MT-ID is in the 128-255 range?

- "BFR-id...If the BFR is not locally configured with a valid BFR-id, the value
of this field is set to invalid BFR-id per [RFC8279]."  I looked in rfc8279 for
the text about "invalid BFR-id", but found this instead: "The value 0 is not a
legal BFR-id."  I assume that in this case "invalid" is the same as "not
legal".  It would be nice to be consistent.

- "When such duplication is detected all BFRs advertising duplicates MUST be
treated as if they did not advertise a valid BFR-id."  How are BFRs that
advertise an invalid BFR-id treated?

- What should a receiver do if the BSL is set to a value not supported in
rfc8296?

- "Label ranges within all BIER MPLS Encapsulation Sub-TLVs advertised by the
same BFR MUST NOT overlap.  If the overlap is detected, the advertising router
MUST be treated as if it did not advertise any BIER sub-TLVs."  If an overlap
is detected, the result is that *all* BFRs (advertising the overlap) are
treated as if the BIER sub-TLV was not advertised, right?  The text is not
clear as to whether the result applies to all or just the BFR that advertised
last (and resulted in the detection happening).

- "All advertised labels MUST be valid..."  What is a "valid" label?

- For the IPA field: "Values are defined in the "IGP    Algorithm Types"
registry."  Please add a reference to this registry.

(2) Security Considerations

- I support Eric's DISCUSS.  It seems to me that an attacker could simply
advertise duplicate BFR-IDs or overlapping label ranges and have a significant
impact on the network.

(3) IANA Considerations

Section 2.2: "The BIER MPLS Encapsulation Sub-TLV is a Sub-TLV of the BIER
Sub-TLV."  However, the type for this sub-sub-TLV is allocated from the OSPF
Extended Prefix sub-TLV registry...and not from a new registry for sub-TLVs for
the BIER Sub-TLV.

---

From: Peter Psenak <[email-masked]>
Date: Thu, 22 Feb 2018 17:57:06 +0100

Hi Alvaro,

please see inline:

> https://datatracker.ietf.org/doc/draft-ietf-bier-ospf-bier-extensions/

rfc4915 says these are "Invalid and SHOULD be ignored" Do we nee to say 
the same here again?

> legal".  It would be nice to be consistent.

would you agree with:

"the value of this field is set to 0, which is defined as illegal in 
[RFC8279].

> advertise an invalid BFR-id treated?

what about:

"as if they did not advertise a legal BFR-id"

> - What should a receiver do if the BSL is set to a value not supported in

what about:

"If the BS length is set to a value that does not match any of the 
allowed values specified in [RFC8296], the BIER MPLS Encapsulation 
Sub-TLV MUST be ignored."

> last (and resulted in the detection happening).

above paragraph talks about the case where a single BFR advertises the 
overlapping label ranges in multiple BIER MPLS Encapsulation Sub-TLVs it 
advertises.

> - "All advertised labels MUST be valid..."  What is a "valid" label?

I'm tempted to get rid of the above statement, as we specified earlier 
that the label "A 3 octet field, where the 20 rightmost bits represent 
the first label" and any value should be fine.

> registry."  Please add a reference to this registry.

do you mean the reference to the draft/RFC where it has been defined? If 
yes, is that mandatory? That registry has been defined in one of the SR 
IGP drafts, that are stuck due to pending dependency on other set of SR 
documents. I did not want to make the BIER dependent on any SR document.

> advertise duplicate BFR-IDs or overlapping label ranges and have a significant

that should be taken care of by protocol authentication and existing 
text covers that:

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

> Extended Prefix sub-TLV registry...and not from a new registry for sub-TLVs for

The OSPFv2 Extended Prefix TLV Sub-TLVs registry "defines sub-TLVs
at any level of nesting for OSPFv2 Extended Prefix TLVs".

We have 16 bits for TLV type in OSPF, so we can afford to do so :)

thanks,
Peter

> .

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 22 Feb 2018 13:22:03 -0500

On 2/22/2018 11:57 AM, Peter Psenak wrote:
> do you mean the reference to the draft/RFC where it has been defined? 
> If yes, is that mandatory? That registry has been defined in one of 
> the SR IGP drafts, that are stuck due to pending dependency on other 
> set of SR documents. I did not want to make the BIER dependent on any 
> SR document. 

This issue has come up recently in a couple of different contexts.

Once a registry exists, and can be found on the IANA pages, a document 
that makes use of that registry should not need to have a reference 
(even an informational reference) to the document that originally 
created the registry.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 22 Feb 2018 15:09:45 -0800

On February 22, 2018 at 1:22:09 PM, Eric C Rosen ([email-masked]) wrote:

do you mean the reference to the draft/RFC where it has been defined? If
yes, is that mandatory? That registry has been defined in one of the SR IGP
drafts, that are stuck due to pending dependency on other set of SR
documents. I did not want to make the BIER dependent on any SR document.

Once a registry exists, and can be found on the IANA pages, a document that
makes use of that registry should not need to have a reference (even an
informational reference) to the document that originally created the
registry.

That fine with me.

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 22 Feb 2018 15:14:05 -0800

On February 22, 2018 at 11:57:08 AM, Peter Psenak ([email-masked]) wrote:

Peter:

Hi!

Yes.  rfc4915 refers specifically to what to do with the value in the LSAs
when used for MTR.

What does it mean to ignore the MT-ID in the BIER Sub-TLV?

For example... "Each BFR sub-domain MUST be associated with one and only
one OSPF topology that is identified by the MT-ID." If the MT-ID is not
known (because it is ignored), then how can we enforce this check?

would you agree with:

Yeah, that’s fine.

Side comment: it’s a shame that rfc8279 chose “illegal” to describe a value
that can be used.

what about:

Sorry…the question is: if the BFD-id is 0, then what?  What needs to be
done by the receiver?

what about:

ok

Yeah…sorry…overlooked that first part.

Well…there are some reserved values… rfc3032…

...

I’ll let Eric handle the DISCUSS and whether he thinks this is ok.

Ah, I see.  That text is buried in rfc7684, and not reflected in the
registry itself.

We’re good then.

Thanks!

Alvaro.

---

From: Peter Psenak <[email-masked]>
Date: Fri, 23 Feb 2018 14:16:46 +0100

Hi Alvaro,

please see inline (##PP):

On 23/02/18 00:14 , Alvaro Retana wrote:
> On February 22, 2018 at 11:57:08 AM, Peter Psenak ([email-masked]
> <mailto:[email-masked]>) wrote:
>
> Peter:
>
> Hi!
>
> Yes.  rfc4915 refers specifically to what to do with the value in the
> LSAs when used for MTR.
>

##PP
ok, I have added the following statement:

"If the MT-ID value is outside of the values specified in [RFC4915], the 
BIER Sub-TLV MUST be ignored."

> Side comment: it’s a shame that rfc8279 chose “illegal” to describe a
> value that can be used.
>
>
>> >

rfc8279, section 5 says:

"      If BFR-A determines that BFR-B and BFR-C have both advertised the
       same BFR-id for the same sub-domain, BFR-A MUST log an error.
       Suppose that the duplicate BFR-id is "N".  When BFR-A is
       functioning as a BFIR, it MUST NOT encode the BFR-id value N in
       the BIER encapsulation of any packet that has been assigned to the
       given sub-domain, even if it has determined that the packet needs
       to be received by BFR-B and/or BFR-C.

       This will mean that BFR-B and BFR-C cannot receive multicast
       traffic at all in the given sub-domain until the provisioning
       error is fixed.  However, that is preferable to having them
       receive each other's traffic.

...

    If a BFR advertises that it has a BFR-id of 0 in a particular
    sub-domain, other BFRs receiving the advertisement MUST interpret
    that advertisement as meaning that the advertising BFR does not have
    a BFR-id in that sub-domain."

So I rewrote the section as:

"All BFRs MUST detect advertisement of duplicate valid BFR-IDs for a 
given MT-ID and Sub-domain-ID. When such duplication is detected by the 
BFR, it MUST behave as described in section 5 of [RFC8279]."

> Well…there are some reserved values… rfc3032…

How to deal with the reserved labels by BIER should have been defined in 
rfc8296 or rfc8279, not in the IGP extension draft really. I have 
removed the following text:

"All advertised labels MUST be valid, otherwise the BIER sub-TLV MUST	be 
ignored.

thanks,
Peter

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 23 Feb 2018 06:58:21 -0800

Peter:

Hi!  Thanks for addressing my comment!

Alvaro.

On February 23, 2018 at 8:16:49 AM, Peter Psenak ([email-masked]) wrote:

Hi Alvaro,

##PP

rfc8279, section 5 says:

...

thanks,
Peter