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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 17 Aug 2015 22:46:40 +0000

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.

Thanks,
Acee

On 8/17/15, 4:06 PM, "Kathleen Moriarty"
<[email-masked]> 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.
>
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 18 Aug 2015 17:20:44 +0000

Hi Kathleen, 

On 8/18/15, 10:57 AM, "Kathleen Moriarty"
<[email-masked]> 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) <[email-masked]>
>wrote:
>> Hi Kathleen,
>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
>>
>>>Please refer to 
>>>https://www.ietf.org/iesg/statement/discuss-criteria.html
>-- 
>Best regards,
>Kathleen

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 18 Aug 2015 19:35:45 +0000

Hi Kathleen, 

On 8/18/15, 1:54 PM, "Kathleen Moriarty"
<[email-masked]> wrote:

>Acee,
>
>On Tue, Aug 18, 2015 at 1:20 PM, Acee Lindem (acee) <[email-masked]>
>wrote:
>> Hi Kathleen,
>>
>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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 18 Aug 2015 19:42:46 +0000

On 8/18/15, 3:38 PM, "Kathleen Moriarty"
<[email-masked]> wrote:

>On Tue, Aug 18, 2015 at 3:35 PM, Acee Lindem (acee) <[email-masked]>
>wrote:
>> Hi Kathleen,
>>
>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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 19 Aug 2015 11:57:59 -0400

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

I hope this clarifies?

Thanks,
Alia

On Wed, Aug 19, 2015 at 10:44 AM, Kathleen Moriarty <
[email-masked]> 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) <[email-masked]>
> wrote:
> >
> >
> >>>>>>>    OSPFv2 applications utilizing these OSPFv2 extensions must
> define
> >>>>>>>the
> >>>>> LSDB and reflooded. This is the reason for using a TLV based encoding
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Aug 2015 18:07:32 +0000

Hi Kathleen, 

On 8/19/15, 2:00 PM, "Kathleen Moriarty"
<[email-masked]> 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 <[email-masked]> wrote:
>> Hi Kathleen,
>>
>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
>>> >>>>>>>    In general, new LSAs defined in this document are subject to
>>> >>>>>>> the
>>> >>>>>>>same
>>> >>>>>>>    security concerns as those described in [OSPFV2] and
>>>[OPAQUE]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Aug 2015 18:44:15 +0000

Hi Kathleen,

On 8/19/15, 2:14 PM, "Kathleen Moriarty"
<[email-masked]> wrote:

>Hi Acee,
>
>On Wed, Aug 19, 2015 at 2:07 PM, Acee Lindem (acee) <[email-masked]>
>wrote:
>> Hi Kathleen,
>>
>>>>http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-
>>>>tl
>>>>vs.xhtml#top-level
>>>> )
>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
>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. 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).

Thanks,
Acee  

>>>>> >>>>>>> Here are the updated "Security Considerations” after
>>>>>addressing
>>>>> >>>>>>>Alvaro’s
>>>>> >>>>>>> comments.
>>>>> >>>>>>>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Aug 2015 19:16:43 +0000

On 8/19/15, 2:58 PM, "Kathleen Moriarty"
<[email-masked]> wrote:

>Hi Acee,
>
>On Wed, Aug 19, 2015 at 2:44 PM, Acee Lindem (acee) <[email-masked]>
>wrote:
>> Hi Kathleen,
>>
>> 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
>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.

Acee 

>>>>>>> >>>>>>Thank you for your quick response, Acee.  I just have one
>>>>>>>tweak
>>>>>>> >>>>>> inline
>>>>>>> >>>>>>>    In general, new LSAs defined in this document are
>>>>>>>subject
>>>>>>>to
>>>>>>> >>>>>>> the
>>>>>>> >>>>>>>same

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Aug 2015 19:31:19 +0000

Hi Kathleen, 

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

>Hi Acee,
>
>On Wed, Aug 19, 2015 at 3:16 PM, Acee Lindem (acee) <[email-masked]>
>wrote:
>>
>>
>>>>>>>> As discussed, the type field in the TLVs and sub-TLVs are limited
>>>>>>>>to
>>>>>>>>their
>>>>>>>> range.
>>>>>>>>http://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-
>>>>>>>>en
>>>>>>>>g-
>>>>>>>>tl
>>>>>>>>vs.xhtml#top-level
>>>>>>>> )
>>>>>>>> throughout the IGP; sometimes, only routers in particular roles
>>>>>>>>will
>>>>>>>>care
>>>>>>>> about the information.
>>>>>>>>
>>>>>> reference beyond the end of the LSA and the LSA should never
>>>>>>overflow
>>>>>>the
>>>>>> end of the OSPF packet.
>>>>>
>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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 20 Aug 2015 13:36:31 +0000

Hi Kathleen,
The -13 version includes the clarifying text.

http://www.ietf.org/id/draft-ietf-ospf-prefix-link-attr-13.txt

Thanks,
Acee

On 8/19/15, 3:34 PM, "Kathleen Moriarty"
<[email-masked]> wrote:

>Hi Acee,
>
>On Wed, Aug 19, 2015 at 3:31 PM, Acee Lindem (acee) <[email-masked]>
>wrote:
>> Hi Kathleen,
>>
>>>>>>>>>> This draft in the IANA considerations specifies what the range
>>>>>>>>>>for
>>>>>>>>>>those
>>>>>>>>>> values are.
>>>>>>>>>> For future extensibility, it is important to be able to
>>>>>>>>>>distribute
>>>>>>>>>>unknown
>>>>>>>>>> TLVs
>>>>>>>>>> However, the length field constrains how big the value can be
>>>>>>>>>>and
>>>>>>>>>>any
>>>>>>>>>> problems
>Thank you, I think that text is much more helpful.
>
>Best regards,
>Kathleen
>
>>
>> Acee
>>
>>
>>>
>>>Thanks,
>>>Kathleen
>>>
>>>>
>>>> Acee
>>>>
>>>>
>>>>>
>>>>>Thanks,
>>>>>Kathleen
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Acee
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>Thank you,
>>>>>>>Kathleen
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Acee
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I hope this clarifies?
>>>>>>>>>
>>>>>>>>>>> Alia and I talked about this yesterday and she will be
>>>>>>>>>>>following
>>>>>>>>>>>up