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

"Acee Lindem (acee)" <acee@cisco.com> Thu, 20 August 2015 13:36 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 84F801A01AA; Thu, 20 Aug 2015 06:36:37 -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 Ao6qj0duP_JY; Thu, 20 Aug 2015 06:36:35 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAAE1ACE57; Thu, 20 Aug 2015 06:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13026; q=dns/txt; s=iport; t=1440077794; x=1441287394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vssiQ4EY5R8unQ768yqRf02SzNES4b0iCDLQ5KhRF+s=; b=jkuxodECpplysNaXPy26LX/tSdGv60VF7vbUULp1Pvd/3uRqngOggh53 REQo4+/+7UfPdWRq2tgk4kuwwW3XLhSGpUDJuwTYSwly4PparvMcvz0Ev 02hVGiP2VgLJIKuO5RHKtdm7aDXUjSLc2wLlSoIrEtPrro4zwR91rtSNc k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoAgBK19VV/4wNJK1dgxtUaQaDH7ovAQmBd4V7AhyBFjgUAQEBAQEBAYEKhCQBAQQjEUUQAgEIGAICJgICAh8RFRACBA4FCYgQAxINuV6QGw2FVwEBAQEBAQEDAQEBAQEBARuBIokugQOCT4FiJjMHgmmBQwWHKoZkhxsBhyyDVYFtgUqROYNPg2kmgj+BPnEBgQRDgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,714,1432598400"; d="scan'208";a="180447470"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 20 Aug 2015 13:36:33 +0000
Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t7KDaXGR028268 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Aug 2015 13:36:33 GMT
Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 20 Aug 2015 08:36:32 -0500
Received: from xhc-rcd-x05.cisco.com (173.37.183.79) by xch-aln-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 20 Aug 2015 08:36:32 -0500
Received: from xmb-aln-x06.cisco.com ([169.254.1.223]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0248.002; Thu, 20 Aug 2015 08:36:31 -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+k2Rr3P197oiCg==
Date: Thu, 20 Aug 2015 13:36:31 +0000
Message-ID: <D1FB5005.2C250%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> <D1FA45FC.2C096%acee@cisco.com> <CAHbuEH7EqE+C2PgpDUpi3zFX7ge3LoarZUfi540s8Mar_M9upA@mail.gmail.com> <D1FA4C59.2C0AC%acee@cisco.com> <CAHbuEH7y9onj-g+wqyQc5G30jv4f7ymcqubGYCaRw3vj_VFWjA@mail.gmail.com> <D1FA50C6.2C0C5%acee@cisco.com> <CAHbuEH63pNtS_5yPWzbAqRMuF1ec+=usaKF5wB68KDcs4aMq=A@mail.gmail.com>
In-Reply-To: <CAHbuEH63pNtS_5yPWzbAqRMuF1ec+=usaKF5wB68KDcs4aMq=A@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: <F3B411210608B94C95B875CE523EF0F2@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/ZtqNmoUKXDId6bHH0ENnkIyWQ8o>
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: Thu, 20 Aug 2015 13:36:37 -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"
<kathleen.moriarty.ietf@gmail.com> wrote:

>Hi Acee,
>
>On Wed, Aug 19, 2015 at 3:31 PM, Acee Lindem (acee) <acee@cisco.com>
>wrote:
>> Hi Kathleen,
>>
>> On 8/19/15, 3:24 PM, "Kathleen Moriarty"
>> <kathleen.moriarty.ietf@gmail.com> wrote:
>>
>>>Hi Acee,
>>>
>>>On Wed, Aug 19, 2015 at 3:16 PM, Acee Lindem (acee) <acee@cisco.com>
>>>wrote:
>>>>
>>>>
>>>> On 8/19/15, 2:58 PM, "Kathleen Moriarty"
>>>> <kathleen.moriarty.ietf@gmail.com> wrote:
>>>>
>>>>>Hi Acee,
>>>>>
>>>>>On Wed, Aug 19, 2015 at 2:44 PM, Acee Lindem (acee) <acee@cisco.com>
>>>>>wrote:
>>>>>> 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-traffi
>>>>>>>>>>c-
>>>>>>>>>>en
>>>>>>>>>>g-
>>>>>>>>>>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.
>>>>>
>>>>>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
>>>>>> implement it in the security considerations of this draft when there
>>>>>>are
>>>>>> probably hundreds that utilize TLVs (or the AVP variation from AAA
>>>>>> specifications).
>>>>>
>>>>>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.
>>>
>>>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.
>
>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?
>>>>>>>>>
>>>>>>>>>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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>--
>>>>>
>>>>>Best regards,
>>>>>Kathleen
>>>>
>>>
>>>
>>>
>>>--
>>>
>>>Best regards,
>>>Kathleen
>>
>
>
>
>-- 
>
>Best regards,
>Kathleen