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

"Acee Lindem (acee)" <acee@cisco.com> Wed, 19 August 2015 18:44 UTC

Return-Path: <acee@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D9A1A007C; Wed, 19 Aug 2015 11:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl3cve4dK2P9; Wed, 19 Aug 2015 11:44:19 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE691A8752; Wed, 19 Aug 2015 11:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7644; q=dns/txt; s=iport; t=1440009860; x=1441219460; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=65Ry2bJjkWxvm1Or6edkEK+SeDaE5J8JLLmm/boRCjo=; b=i1N2ELvjdAIFcrW5NEaCHjg5gbDJ132SjUphnya4uyPtiPA/wu6Gxh+3 KlfN/G6S47FMHk8gDBkEzyUM0v1gCFgs0DZitF858KFpPeNTwbqIusGbt sYQeIzh26Xq/N2xWGOW2INzYj3nVtZMWB0g4J7OGxv77WcA1ffYyJDLUw A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CGAgBPzdRV/40NJK1dgxtUaQaDH7o0AQmBd4V7AhyBKTgUAQEBAQEBAYEKhCQBAQQjEUUQAgEIGAICJgICAh8RFRACBA4FCYgQAxINuSiQNg2FVwEBAQEBAQEBAgEBAQEBAQEbgSKKMYJPgWImMweCaYFDBZUkAYcrg1SBbYFKkTCDT4NoJoI/gT5xAYEEQ4EEAQEB
X-IronPort-AV: E=Sophos;i="5.15,711,1432598400"; d="scan'208";a="179574677"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 19 Aug 2015 18:44:18 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t7JIiHfr030750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 19 Aug 2015 18:44:17 GMT
Received: from xch-aln-006.cisco.com (173.36.7.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 19 Aug 2015 13:44:16 -0500
Received: from xhc-rcd-x13.cisco.com (173.37.183.87) by xch-aln-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 19 Aug 2015 13:44:16 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0248.002; Wed, 19 Aug 2015 13:44:16 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-ospf-prefix-link-attr-10: (with DISCUSS)
Thread-Index: AQHQ2T4vD1u2/uPu+k2Rr3P197oiCp4SLaKA///lEgCAAEyNgP//2HWAgABEpwD//74IgAAsnZPNAAJZlYAACJyhAP//xV6A
Date: Wed, 19 Aug 2015 18:44:15 +0000
Message-ID: <D1FA45FC.2C096%acee@cisco.com>
References: <20150817200640.5272.4712.idtracker@ietfa.amsl.com> <D1F7DABC.2BC37%acee@cisco.com> <CAHbuEH4Cwj4EmiqpBmb1g+SVezPNjJff9RiMuVi-B0EmtSTF2Q@mail.gmail.com> <D1F8DE85.2BD4C%acee@cisco.com> <CAHbuEH7f=qFnj3SrgDvP=Dnmp93GWzPGyBgP+6dvp-GA_=dLBA@mail.gmail.com> <D1F9004C.2BD9D%acee@cisco.com> <CAHbuEH4wwar_CnrS9WMFcZrexRwNPDtjc8pWtGFOXobCU9hN_A@mail.gmail.com> <D1F9025A.2BDBA%acee@cisco.com> <CAHbuEH6p9nsK=RGq5qtN4O2BEaO5AmEhrOTHz-1B++REuZS_RA@mail.gmail.com> <CAG4d1rfgD50kCmprXY4CG9rvTadcd7UZDYz3M2uoyawbmUDivA@mail.gmail.com> <CAHbuEH6rOvzzqJT3fHR8C=-kVJiT2ajx2nGFwuwGgUMtGE6y1w@mail.gmail.com> <D1FA3D76.2C070%acee@cisco.com> <CAHbuEH5RmTP29Ow2Xce4GNKWJSu647oTLYGqYg=PBRJbUuQthA@mail.gmail.com>
In-Reply-To: <CAHbuEH5RmTP29Ow2Xce4GNKWJSu647oTLYGqYg=PBRJbUuQthA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.37.102.24]
Content-Type: text/plain; charset="utf-8"
Content-ID: <1982A31774A82046A0607306012DB626@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/qzroDv3vDOYtVKE4gRe-G22j15A>
Cc: "ospf@ietf.org" <ospf@ietf.org>, "draft-ietf-ospf-prefix-link-attr@ietf.org" <draft-ietf-ospf-prefix-link-attr@ietf.org>, "draft-ietf-ospf-prefix-link-attr.shepherd@ietf.org" <draft-ietf-ospf-prefix-link-attr.shepherd@ietf.org>, "draft-ietf-ospf-prefix-link-attr.ad@ietf.org" <draft-ietf-ospf-prefix-link-attr.ad@ietf.org>, The IESG <iesg@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>
Subject: Re: [OSPF] Kathleen Moriarty's Discuss on draft-ietf-ospf-prefix-link-attr-10: (with DISCUSS)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2015 18:44:21 -0000

Hi Kathleen,

On 8/19/15, 2:14 PM, "Kathleen Moriarty"
<kathleen.moriarty.ietf@gmail.com> wrote:

>Hi Acee,
>
>On Wed, Aug 19, 2015 at 2:07 PM, Acee Lindem (acee) <acee@cisco.com>
>wrote:
>> Hi Kathleen,
>>
>> On 8/19/15, 2:00 PM, "Kathleen Moriarty"
>> <kathleen.moriarty.ietf@gmail.com> 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 <akatlas@gmail.com> 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.
>
>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
>>>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.
>
>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  





>
>Thank you,
>Kathleen
>
>>
>> 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
>>>> <kathleen.moriarty.ietf@gmail.com> 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) <acee@cisco.com>
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> > On 8/18/15, 3:38 PM, "Kathleen Moriarty"
>>>>> > <kathleen.moriarty.ietf@gmail.com> wrote:
>>>>> >
>>>>> >>On Tue, Aug 18, 2015 at 3:35 PM, Acee Lindem (acee)
>>>>><acee@cisco.com>
>>>>> >>wrote:
>>>>> >>> Hi Kathleen,
>>>>> >>>
>>>>> >>> On 8/18/15, 1:54 PM, "Kathleen Moriarty"
>>>>> >>> <kathleen.moriarty.ietf@gmail.com> wrote:
>>>>> >>>
>>>>> >>>>Acee,
>>>>> >>>>
>>>>> >>>>On Tue, Aug 18, 2015 at 1:20 PM, Acee Lindem (acee)
>>>>><acee@cisco.com>
>>>>> >>>>wrote:
>>>>> >>>>> Hi Kathleen,
>>>>> >>>>>
>>>>> >>>>> On 8/18/15, 10:57 AM, "Kathleen Moriarty"
>>>>> >>>>> <kathleen.moriarty.ietf@gmail.com> 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)
>>>>><acee@cisco.com>
>>>>> >>>>>>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]
>>
>
>
>
>-- 
>
>Best regards,
>Kathleen