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/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].
>>
>>    OSPFv2 applications utilizing these OSPFv2 extensions must define the
>>    security considerations relating to those applications in the
>>    the specifications corresponding to those applications.
>>
>>    Additionally, implementations must assure that malformed TLV and Sub-
>>    TLV permutations are detected and do not provide a vulnerability for
>>    attackers to crash the OSPFv2 router or routing process.  Malformed
>>    LSAs MUST NOT be stored in the Link State Database (LSDB),
>>    acknowledged, or reflooded.  Reception of malformed LSAs SHOULD be
>>    counted or logged for further analysis.
>
>Can you add in a sentence that says something to the effect of:
>
>Only valid TLVs and Sub-TLVs may be processed according to
>specifications in section 2.

This depends on how you define “valid”. For extendability, an
implementation considers any TLV or Sub-TLV that is properly formed as
valid. Of course, it only uses the TLV and Sub-TLVs that it knows how to
interpret. Hence, the LSA will be considered valid and be stored in the
LSDB and reflooded. This is the reason for using a TLV based encoding.

>
>Something similar for LSAs as well.

Opaque LSAs [RFC 5250] are valid even if the opaque type is not
recognized. 

Thanks,
Acee 





>
>A variation of that is fine.  The main point being that you usually
>want to accept only what is valid in a programming sense because of
>you look for the malformed, you could miss something and wind up with
>an unexpected condition as opposed to only accepting what is valid.
>
>Thank you,
>Kathleen
>
>>
>>
>> Thanks,
>> Acee
>>
>> On 8/17/15, 4:06 PM, "Kathleen Moriarty"
>> <[e-mail]> wrote:
>>
>>>Kathleen Moriarty has entered the following ballot position for
>>>draft-ietf-ospf-prefix-link-attr-10: Discuss
>>>
>>>When responding, please keep the subject line intact and reply to all
>>>email addresses included in the To and CC lines. (Feel free to cut this
>>>introductory paragraph, however.)
>>>
>>>
>>>Please refer to 
>>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>>>for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>>The document, along with other ballot positions, can be found here:
>>>https://datatracker.ietf.org/doc/draft-ietf-ospf-prefix-link-attr/
>>>
>>>
>>>
>>>----------------------------------------------------------------------
>>>DISCUSS:
>>>----------------------------------------------------------------------
>>>
>>>Thanks for your work on this draft.
>>>
>>>I have questions along the lines that Alvaro raised on the last sentence
>>>of the Security Considerations section, but in context of security, this
>>>is something that should be discussed.
>>>
>>>  "Additionally,
>>>   implementations must assure that malformed TLV and Sub-TLV
>>>   permutations do not result in errors that cause hard OSPF failures."
>>>
>>>It would be very helpful to expand upon this statement.  Are there
>>>exploits that could result as well?  Should this instead be scoped in
>>>terms of what is valid so that the appropriate actions occur
>>>consistently
>>>when an invalid or malformed TLV or sub-TLV are received?  I would think
>>>the answer to the last question would clarify this enough for this
>>>security consideration and if that's not possible, can you explain what
>>>I'm missing?
>>>
>>>Thank you.
>>>
>>>
>>>
>>
>
>
>
>-- 
>
>Best regards,
>Kathleen