On 8/18/15, 3:38 PM, "Kathleen Moriarty" <[email protected]> wrote:
>On Tue, Aug 18, 2015 at 3:35 PM, Acee Lindem (acee) <[email protected]> >wrote: >> 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. > >I was hoping for text in the positive direction, meaning that you >accept what is valid and the rest is not valid or malformed and >therefore not accepted. You avoid potential problems this way with >unexpected conditions being reached. Can you change the text a >little? Actually we do not accept an LSA if it is malformed so the acceptance granularity is always at the LSA level. Opaque types, TLVs, and Sub-TLVs that are unrecognized are accepted as long as they can be parsed successfully. What do you suggest? Thanks, Acee > >Thanks, >Kathleen > >> >> 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 >> > > > >-- > >Best regards, >Kathleen _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
