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

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

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].
>>>>>>
>>>>>>    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.
>
>I was hoping for text in the positive direction, meaning that you
>accept what is valid and the rest is not valid or malformed and
>therefore not accepted.  You avoid potential problems this way with
>unexpected conditions being reached.   Can you change the text a
>little?

Actually we do not accept an LSA if it is malformed so the acceptance
granularity is always at the LSA level. Opaque types, TLVs, and Sub-TLVs
that are unrecognized are accepted as long as they can be parsed
successfully. What do you suggest?

Thanks,
Acee 






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