Hi Kathleen, On 8/19/15, 3:24 PM, "Kathleen Moriarty" <kathleen.moriarty.i...@gmail.com> wrote:
>Hi Acee, > >On Wed, Aug 19, 2015 at 3:16 PM, Acee Lindem (acee) <a...@cisco.com> >wrote: >> >> >> 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. > >I don't agree with the proposed text in the way it is written that you >provided in response to Alvaro's questions. You are adding text that >does almost what I am asking, but says malformed are rejected. There >is just no way to know what to accept/reject from this language. If >there was a pointer to another draft, that would be great. How about this: In this context, a malformed LSA is one which cannot be parsed due to a TLV or Sub-TLV overrunning the end of the subsuming LSA, TLV, or sub-TLV or where there is data remaining to be parsed but the length of the remaining data is less than the size of a TLV header. These are the situations that can cause a routing process to crash. Acee > >Thanks, >Kathleen > >> >> 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 >> > > > >-- > >Best regards, >Kathleen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
