Hi Kathleen, As discussed, the type field in the TLVs and sub-TLVs are limited to their range. This draft in the IANA considerations specifies what the range for those values are. This is just as has been done with other OSPF TLVs ( for example http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#top-level ) For future extensibility, it is important to be able to distribute unknown TLVs throughout the IGP; sometimes, only routers in particular roles will care about the information.
However, the length field constrains how big the value can be and any problems with parsing it into an opaque value would cause the LSA to be considered malformed. I hope this clarifies? Thanks, Alia On Wed, Aug 19, 2015 at 10:44 AM, Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > Hi Acee, > > Alia and I talked about this yesterday and she will be following up > from that discussion. It may just point back to previous RFCs that > cover my concern or may result in a change to text. > > Stand by... > > Thank you. > > On Tue, Aug 18, 2015 at 3:42 PM, Acee Lindem (acee) <a...@cisco.com> > wrote: > > > > > > On 8/18/15, 3:38 PM, "Kathleen Moriarty" > > <kathleen.moriarty.i...@gmail.com> wrote: > > > >>On Tue, Aug 18, 2015 at 3:35 PM, Acee Lindem (acee) <a...@cisco.com> > >>wrote: > >>> Hi Kathleen, > >>> > >>> On 8/18/15, 1:54 PM, "Kathleen Moriarty" > >>> <kathleen.moriarty.i...@gmail.com> wrote: > >>> > >>>>Acee, > >>>> > >>>>On Tue, Aug 18, 2015 at 1:20 PM, Acee Lindem (acee) <a...@cisco.com> > >>>>wrote: > >>>>> Hi Kathleen, > >>>>> > >>>>> On 8/18/15, 10:57 AM, "Kathleen Moriarty" > >>>>> <kathleen.moriarty.i...@gmail.com> wrote: > >>>>> > >>>>>>Thank you for your quick response, Acee. I just have one tweak > inline > >>>>>>that is usually important from a security standpoint. > >>>>>> > >>>>>>On Mon, Aug 17, 2015 at 6:46 PM, Acee Lindem (acee) <a...@cisco.com> > >>>>>>wrote: > >>>>>>> Hi Kathleen, > >>>>>>> Here are the updated "Security Considerations” after addressing > >>>>>>>Alvaro’s > >>>>>>> comments. > >>>>>>> > >>>>>>> 6. Security Considerations > >>>>>>> > >>>>>>> In general, new LSAs defined in this document are subject to the > >>>>>>>same > >>>>>>> security concerns as those described in [OSPFV2] and [OPAQUE]. > >>>>>>> > >>>>>>> OSPFv2 applications utilizing these OSPFv2 extensions must > define > >>>>>>>the > >>>>>>> security considerations relating to those applications in the > >>>>>>> the specifications corresponding to those applications. > >>>>>>> > >>>>>>> Additionally, implementations must assure that malformed TLV and > >>>>>>>Sub- > >>>>>>> TLV permutations are detected and do not provide a vulnerability > >>>>>>>for > >>>>>>> attackers to crash the OSPFv2 router or routing process. > >>>>>>>Malformed > >>>>>>> LSAs MUST NOT be stored in the Link State Database (LSDB), > >>>>>>> acknowledged, or reflooded. Reception of malformed LSAs SHOULD > >>>>>>>be > >>>>>>> counted or logged for further analysis. > >>>>>> > >>>>>>Can you add in a sentence that says something to the effect of: > >>>>>> > >>>>>>Only valid TLVs and Sub-TLVs may be processed according to > >>>>>>specifications in section 2. > >>>>> > >>>>> This depends on how you define “valid”. For extendability, an > >>>>> implementation considers any TLV or Sub-TLV that is properly formed > as > >>>>> valid. Of course, it only uses the TLV and Sub-TLVs that it knows how > >>>>>to > >>>>> interpret. Hence, the LSA will be considered valid and be stored in > >>>>>the > >>>>> LSDB and reflooded. This is the reason for using a TLV based encoding >
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
