Hi Kathleen, On 8/19/15, 2:14 PM, "Kathleen Moriarty" <kathleen.moriarty.i...@gmail.com> wrote:
>Hi Acee, > >On Wed, Aug 19, 2015 at 2:07 PM, Acee Lindem (acee) <a...@cisco.com> >wrote: >> Hi Kathleen, >> >> On 8/19/15, 2:00 PM, "Kathleen Moriarty" >> <kathleen.moriarty.i...@gmail.com> wrote: >> >>>Hi Alia, >>> >>>Thanks for the write up. I have a couple of questions in-line. >>> >>>On Wed, Aug 19, 2015 at 11:57 AM, Alia Atlas <akat...@gmail.com> wrote: >>>> 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- >>>>tl >>>>vs.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. >>> >>>But there are no restrictions on values that have not been defined and >>>they are stored and forwarded anyway? This is the main concern in >>>that there are no checks on these values (and I'm assuming there are >>>programming checks on the defined values whose length can vary in >>>terms of the # of octets for any value and could be 4 to 32 or more >>>octets). Because of the range of acceptable length values for defined >>>TLVs, it would be hard to know if you have something malformed or >>>containing an exploit on undefined values, right? >> >> If it is malformed, it would be highly unlikely that all the length >> parsing would come out correctly. The key is that you NEVER want to >> reference beyond the end of the LSA and the LSA should never overflow >>the >> end of the OSPF packet. > >I can appreciate your point on malformed, but checking in the positive >direction (what is allowed) is more useful than checking for a number >of conditions that would make it malformed as it is easier to miss >something if you don't test for all conditions that make it malformed. > >Is there a way to rephrase the wording so that the check is to ensure >expected conditions are met as opposed to it 'not being malformed'. I >tried previously and you didn't like the suggestion, could you propose >something? > >> >>>What if a code >>>condition was reached because an undefined value is stored and >>>'reflooded' to all the peers? >> >> If, by chance, the parsing came out correctly, the malformed information >> in the LSA would simply be interpreted as unknown TLVs. > >How would you know it is malformed? What conditions are checked? The TLV is almost as old as networking itself. You simply want to assure that none of the nested pieces overrun the subsuming pieces with the LSA being at the top level. I don’t think I need to tell people how to implement it in the security considerations of this draft when there are probably hundreds that utilize TLVs (or the AVP variation from AAA specifications). Thanks, Acee > >Thank you, >Kathleen > >> >> Thanks, >> Acee >> >> >>> >>>> >>>> I hope this clarifies? >>> >>>Yes, thank you, but I'm still a little concerned. >>> >>>Thanks, >>>Kathleen >>>> >>>> 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] >> > > > >-- > >Best regards, >Kathleen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
