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. > >Something similar for LSAs as well. Opaque LSAs [RFC 5250] are valid even if the opaque type is not recognized. Thanks, Acee > >A variation of that is fine. The main point being that you usually >want to accept only what is valid in a programming sense because of >you look for the malformed, you could miss something and wind up with >an unexpected condition as opposed to only accepting what is valid. > >Thank you, >Kathleen > >> >> >> 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. >>> >>> >>> >> > > > >-- > >Best regards, >Kathleen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
