Hi Kathleen, The -13 version includes the clarifying text. http://www.ietf.org/id/draft-ietf-ospf-prefix-link-attr-13.txt
Thanks, Acee On 8/19/15, 3:34 PM, "Kathleen Moriarty" <kathleen.moriarty.i...@gmail.com> wrote: >Hi Acee, > >On Wed, Aug 19, 2015 at 3:31 PM, Acee Lindem (acee) <a...@cisco.com> >wrote: >> 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-traffi >>>>>>>>>>c- >>>>>>>>>>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. > >Thank you, I think that text is much more helpful. > >Best regards, >Kathleen > >> >> 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 >> > > > >-- > >Best regards, >Kathleen _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
