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

[Stephen Farrell <[e-mail]>]

On 19/08/15 17:46, Acee Lindem (acee) wrote:
> Hi Stephen, 
> 
> On 8/19/15, 11:51 AM, "Stephen Farrell" <[e-mail]> wrote:
> 
>> 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? 
> 
> 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.

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

> 
> 
>> 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?)
> 
> The scope of the Opaque ID is only the originating router so each has its
> own number space.  

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

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

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

S.

> 
> 
>>
>> - Thanks for section 5. Nice to see. (Makes me wonder what
>> those implementations do with the opaque ID though:-)
> 
> The Opaque ID is just used as a key for LSAs.
> 
> Thanks,
> Acee
> 
> 
>>
>>
>