Re: [OSPF] Kathleen Moriarty's Discuss on draft-ietf-ospf-prefix-link-attr-10: (with DISCUSS)

["Acee Lindem (acee)" <[e-mail]>]

On 8/19/15, 2:58 PM, "Kathleen Moriarty"
<[e-mail]> wrote:

>Hi Acee,
>
>On Wed, Aug 19, 2015 at 2:44 PM, Acee Lindem (acee) <[e-mail]>
>wrote:
>> Hi Kathleen,
>>
>> On 8/19/15, 2:14 PM, "Kathleen Moriarty"
>> <[e-mail]> wrote:
>>
>>>Hi Acee,
>>>
>>>On Wed, Aug 19, 2015 at 2:07 PM, Acee Lindem (acee) <[e-mail]>
>>>wrote:
>>>> Hi Kathleen,
>>>>
>>>> On 8/19/15, 2:00 PM, "Kathleen Moriarty"
>>>> <[e-mail]> 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 <[e-mail]>
>>>>>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
>>>>>> <[e-mail]> 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)
>>>>>>><[e-mail]>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> > On 8/18/15, 3:38 PM, "Kathleen Moriarty"
>>>>>>> > <[e-mail]> wrote:
>>>>>>> >
>>>>>>> >>On Tue, Aug 18, 2015 at 3:35 PM, Acee Lindem (acee)
>>>>>>><[e-mail]>
>>>>>>> >>wrote:
>>>>>>> >>> Hi Kathleen,
>>>>>>> >>>
>>>>>>> >>> On 8/18/15, 1:54 PM, "Kathleen Moriarty"
>>>>>>> >>> <[e-mail]> wrote:
>>>>>>> >>>
>>>>>>> >>>>Acee,
>>>>>>> >>>>
>>>>>>> >>>>On Tue, Aug 18, 2015 at 1:20 PM, Acee Lindem (acee)
>>>>>>><[e-mail]>
>>>>>>> >>>>wrote:
>>>>>>> >>>>> Hi Kathleen,
>>>>>>> >>>>>
>>>>>>> >>>>> On 8/18/15, 10:57 AM, "Kathleen Moriarty"
>>>>>>> >>>>> <[e-mail]> 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)
>>>>>>><[e-mail]>
>>>>>>> >>>>>>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