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, 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].
>>>>
>>>>    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.
>>
>
>Do you have alternate text to propose to get the same point across?

I think that the text indicating not to store, acknowledge, or
re-advertise LSAs with malformed TLVs will suffice. The handling of
unknown TLVs, Sub-TLVs, and opaque types is well-known to those skilled in
the art. 

Thanks,
Acee 





>
>Thanks,
>Kathleen
>
>>>
>>>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
>>
>
>
>
>-- 
>
>Best regards,
>Kathleen