On 8/19/15, 2:58 PM, "Kathleen Moriarty" <kathleen.moriarty.i...@gmail.com> wrote:
>Hi Acee, > >On Wed, Aug 19, 2015 at 2:44 PM, Acee Lindem (acee) <a...@cisco.com> >wrote: >> 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-en >>>>>>g- >>>>>>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. > >If this is what is meant by not malformed, I think the explanation is >clearer. There are other cases as well. This would be a better topic for an informational draft than here. > > >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). > >It's the same point, but written more clearly for developers of code >than what you have proposed. I think this is helpful as companies >hire new people to code all the time. The “Security Considerations” of this draft is not the place for a treatise on TLV parsing. Acee > >Thanks, >Kathleen > >> >> 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 >> > > > >-- > >Best regards, >Kathleen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
