Hi Kathleen, On 8/18/15, 1:54 PM, "Kathleen Moriarty" <[email protected]> wrote:
>Acee, > >On Tue, Aug 18, 2015 at 1:20 PM, Acee Lindem (acee) <[email protected]> >wrote: >> Hi Kathleen, >> >> On 8/18/15, 10:57 AM, "Kathleen Moriarty" >> <[email protected]> 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) <[email protected]> >>>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. >> > >Do you have alternate text to propose to get the same point across? I think that the text indicating not to store, acknowledge, or re-advertise LSAs with malformed TLVs will suffice. The handling of unknown TLVs, Sub-TLVs, and opaque types is well-known to those skilled in the art. Thanks, Acee > >Thanks, >Kathleen > >>> >>>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" >>>> <[email protected]> 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 >> > > > >-- > >Best regards, >Kathleen _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
