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

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

Hi Kathleen, 

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

>Hi Acee,
>
>On Wed, Aug 19, 2015 at 3:16 PM, Acee Lindem (acee) <[e-mail]>
>wrote:
>>
>>
>> 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.
>
>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
>>>>>>>> <[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
>>
>
>
>
>-- 
>
>Best regards,
>Kathleen