On 8/19/15, 12:55 PM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> wrote:
> > >On 19/08/15 17:46, Acee Lindem (acee) wrote: >> Hi Stephen, >> >> On 8/19/15, 11:51 AM, "Stephen Farrell" <stephen.farr...@cs.tcd.ie> >>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?) 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. > >> >> >>> 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. 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. > >> >>> >>> - 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.) No - I wouldn’t mention it. Thanks, Acee > >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 >> >> >>> >>> >> _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
