Subject: [OSPF] Stephen Farrell's No Objection on draft-ietf-ospf-prefix-link-attr-12: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 19 Aug 2015 08:51:47 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-ospf-prefix-link-attr-12: 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-ospf-prefix-link-attr/

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

- The opaque ID field descriptions in sections 2 and 3 read a
little oddly to me. What happens if someone decides to use up
ID=0? Does that mean they can't overwrite that value until
much later maybe? And what if a whole bunch of routers choose
the same value (because it's configured or hard-coded)? I
think you need a bit more text on that. And with only 24 bits
the probability of a collision if you just pick randomly isn't
that low, so I'm not sure if random selection is a good plan
here either. (How often will a new one of these be seen?)

- Do these opaque values get forwarded widely? If so, then I
guess they may provide a covert channel. I didn't see that
mentioned in the security considerations of RFC5250. Is it
mentioned elsewhere? If not, is it worth a mention here?
(Probably not, but thought I'd ask.)

- Thanks for section 5. Nice to see. (Makes me wonder what
those implementations do with the opaque ID though:-)

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Aug 2015 16:46:31 +0000

Hi Stephen, 

On 8/19/15, 11:51 AM, "Stephen Farrell" <[email-masked]> wrote:

>much later maybe? 

Since it is only to provide uniqueness for opaque LSAs of the same type
originated by the same router, there is no consequence of using 0.

>And what if a whole bunch of routers choose

The scope of the Opaque ID is only the originating router so each has its
own number space.  

>(Probably not, but thought I'd ask.)

Unlike unused protocol fields, it is not really covert since it is a part
of the OSPF LSA ID and is viewable in OSPF OAM and logs. Since it is just
a number, one could, however, set it arbitrarily.

>those implementations do with the opaque ID though:-)

The Opaque ID is just used as a key for LSAs.

Thanks,
Acee

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Aug 2015 17:55:57 +0100

> originated by the same router, there is no consequence of using 0.

Well one cannot send a value less than zero though can you? Which
means that you can't supercede the one that used zero I think. (It
says the lowest value has precedence doesn't it?)

> The scope of the Opaque ID is only the originating router so each has its

Where does it say that? Sorry if I missed it.

> a number, one could, however, set it arbitrarily.

So that's a "no, no need to mention that" then is it? (Which is ok.)

S.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Aug 2015 17:03:32 +0000

On 8/19/15, 12:55 PM, "Stephen Farrell" <[email-masked]> wrote:

>>> Please refer to
>>>https://www.ietf.org/iesg/statement/discuss-criteria.html

Normally, you’d re-originate an LSA to change it. So the recommendation is
to use the latest information (by originating them in ascending order and
using one with the lowest Opaque ID). During the transient re-origination
period, the same prefix or link may be advertised in multiple LSAs.

>Where does it say that? Sorry if I missed it.

You would need to go back to the base protocol specification (RFC 2328):

    12.1.  The LSA Header

        The LSA header contains the LS type, Link State ID and
        Advertising Router fields.  The combination of these three
        fields uniquely identifies the LSA.

        There may be several instances of an LSA present in the
        Autonomous System, all at the same time.  It must then be
        determined which instance is more recent.  This determination is
        made by examining the LS sequence, LS checksum and LS age
        fields.  These fields are also contained in the 20-byte LSA
        header.

        Several of the OSPF packet types list LSAs.  When the instance
        is not important, an LSA is referred to by its LS type, Link
        State ID and Advertising Router (see Link State Request
        Packets).  Otherwise, the LS sequence number, LS age and LS
        checksum fields must also be referenced.

>So that's a "no, no need to mention that" then is it? (Which is ok.)

No - I wouldn’t mention it.

Thanks,
Acee