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, 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-eng-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.

>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.

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]