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. Thanks, Acee On 8/17/15, 4:06 PM, "Kathleen Moriarty" <kathleen.moriarty.i...@gmail.com> wrote: >Kathleen Moriarty has entered the following ballot position for >draft-ietf-ospf-prefix-link-attr-10: Discuss > >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/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >Thanks for your work on this draft. > >I have questions along the lines that Alvaro raised on the last sentence >of the Security Considerations section, but in context of security, this >is something that should be discussed. > > "Additionally, > implementations must assure that malformed TLV and Sub-TLV > permutations do not result in errors that cause hard OSPF failures." > >It would be very helpful to expand upon this statement. Are there >exploits that could result as well? Should this instead be scoped in >terms of what is valid so that the appropriate actions occur consistently >when an invalid or malformed TLV or sub-TLV are received? I would think >the answer to the last question would clarify this enough for this >security consideration and if that's not possible, can you explain what >I'm missing? > >Thank you. > > > _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
