Re: [CCAMP] Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)
Alvaro Retana <aretana.ietf@gmail.com> Tue, 28 November 2017 20:15 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4D4126D0C; Tue, 28 Nov 2017 12:15:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 b18Mi_zBx5If; Tue, 28 Nov 2017 12:15:00 -0800 (PST)
Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECD11204DA; Tue, 28 Nov 2017 12:15:00 -0800 (PST)
Received: by mail-ot0-x233.google.com with SMTP id v21so1024126oth.6; Tue, 28 Nov 2017 12:15:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=uCFEnRGZ5KzPsWaF3pZw/ejiY/xzmCJUpawcTdycU1I=; b=RlCWWt/fu4P1u6zys/rGRLggEVdUg1uxbQE6NMn/L/jLrAMHn0x0FLbE7DaJW9KULZ UytOWJJN6agNtkBtihgtsKI/Rn+u6sC1Em29XWeGLLyMY2AnZZ49zOYIiEo6vqXjZrJL HhDMY+6Ktd0HLzVNYbzjElMDGPRDL+Q8Bz9YWFfNJV5Wc7hGZvTWWMxADpUlHWv/0zSl sVsFm6CVdB9bW4Ib5Z2AmSO0titbuV8I0P05kTiFo3vx7bsQW+pc4vVn4xrBwp7pDjJD 4eZYGWGW/npEm7BVSbFOA6POYJXhh+vy5ChqsrrB7xqgRFr1iBinJUgHPhkMe7HtdziR H68A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=uCFEnRGZ5KzPsWaF3pZw/ejiY/xzmCJUpawcTdycU1I=; b=cdAn/fjwvY3sZbWoq2Sa89ZahR4YsoHXcQw+NPHPdK0GPeoT1Rx9iCu/KatygL0CPH vtB8Q5f+v4UoF4ADGdHulN2bVqq/pyKPrHthLC4JHyBIPlZz8Ta5vPOoePQh2nYZ6lR+ trScP0ztsr79GPh4N2JBmify3OmhybVaI6nTPjVT0IQg/2q1459A4bIBbDudd+KOzLt9 jdoqgKI/RqSKBA/wWOLeUz7ujVVKVT+tRYyj/3hrAHliZbNdqrUJNxeUn3i/0ypenFGf XGfkpI6B9glA6ghExJTWXjJKbkXmADGSo0KuJGg6qUozVGCoqMHtk77QjM/Ppl//vAjN IA3Q==
X-Gm-Message-State: AJaThX4diasOcdm/yfGLlSr3AXTLTf5YSws9foxcLxEZhto9Dnb72ggQ b6sVQiV4oZTU9dgZmxVKhH/3F4sxMee9fHnC+NA=
X-Google-Smtp-Source: AGs4zMbys/8WgnQ5AvjQI1Xtm3SYWjQ0Hk2xTPWkOT2YTuzVRnEqDH1Ak7I7Tzih0tZgF0fYdBUQCZmCH4zOzt3p/lY=
X-Received: by 10.157.73.151 with SMTP id g23mr312052otf.164.1511900099537; Tue, 28 Nov 2017 12:14:59 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 28 Nov 2017 12:14:58 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <HE1PR0701MB2714C95C04A08482402C103FF0480@HE1PR0701MB2714.eurprd07.prod.outlook.com>
References: <150766267307.13579.9907623355727477623.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FC7591FFA@DGGEMA501-MBX.china.huawei.com> <CAMMESszqT+Tj6iVg8SBdAsmC3hkX9N7WDsMqZLo98H4H50uwPQ@mail.gmail.com> <HE1PR0701MB2714C95C04A08482402C103FF0480@HE1PR0701MB2714.eurprd07.prod.outlook.com>
X-Mailer: Airmail (461)
MIME-Version: 1.0
Date: Tue, 28 Nov 2017 12:14:58 -0800
Message-ID: <CAMMESszDqJCkWg1yrgjxAuLr+bKEZU=r+cP1Xsi3U5GKVeByhg@mail.gmail.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Yemin (Amy)" <amy.yemin@huawei.com>
Cc: Fatai Zhang <zhangfatai@huawei.com>, "draft-ietf-ccamp-ospf-availability-extension@ietf.org" <draft-ietf-ccamp-ospf-availability-extension@ietf.org>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, The IESG <iesg@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Content-Type: multipart/alternative; boundary="f40304378ea85e6f9e055f10ac8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/MdLOb3VBleFklLdkyGhjR5eLVw8>
Subject: Re: [CCAMP] Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Nov 2017 20:15:08 -0000
Daniele/Amy: Hi! Sorry for the long delay. In short — no, the proposed text doesn’t address my concern because I think that the extension being defined here can have an impact on routing. Let me try and make my point (about the Security Considerations) again: This document defines an extension that "can be used for route computation in a network that contains links with variable discrete bandwidth” — but "the use of the distributed information for route computation are [sic] outside the scope of this document”. IOW, the intent of the extension is to provide information that can be used to calculate routes, even if the document doesn’t say how to figure out those routes. The Security Considerations then says that "This document does not introduce security issues beyond those discussed in [RFC4203]…the extensions specified here have no direct effect on IP routing.” If the extension can be used for route computation, how can it have no direct effect on routing? Maybe we’re just talking about semantics from the point of view that OSPF is not using the extensions for IP routing (which is true), but someone will be! From the point of view of someone using the extension to calculate routes, then tampering/changing the LSAs could have an impact on the routing decisions, right? IOW, I think that (even if OSPF is not using the information itself) there’s a threat that can be realized from changing the contents of this extension that may result in inconsistent or incorrect routing. Looking closer at rfc4203, the information there can clearly also be used for making routing decisions — again, not by OSPF but by the consumer of the information. I can’t of course do anything wrt that text… In summary, I can see the point that the extension doesn’t cause issues for OSPF…but I think the document is incomplete if it doesn’t address the potential risk to the consumer of the information. In the end, these are non-blocking comments — I’ll defer to whatever you decide. Thanks! Alvaro. On October 13, 2017 at 8:52:45 AM, Daniele Ceccarelli ( daniele.ceccarelli@ericsson.com) wrote: Hi Alvaro, thanks a lot for your review, the text is being improved significantly. I just wanted to add a comment to the discussion on the security section. The text Amy is proposing is exactly the one you can find in RFC4203: This document specifies the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for SPF computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with GMPLS TE LSAs may have an effect on the underlying transport (optical and/or SONET-SDH) network. [OSPF-TE <https://tools.ietf.org/html/rfc4203#ref-OSPF-TE>] suggests mechanisms such as [OSPF-SIG <https://tools.ietf.org/html/rfc4203#ref-OSPF-SIG>] to protect the transmission of this information, and those or other mechanisms should be used to secure and/or authenticate the information carried in the Opaque LSAs. I might agree or disagree with your concern (actually tend to agree), but this is not an issue we can solve in this draft, since it is inherited by a previous RFC. This draft is only defining a new sub-TLV inside the ISCD tlv, like many other existing RFCs. We have the same reference in many existing RFC, like for example RFC7138. What RFC 7138 adds is a reference to RFC5920 that could work also in our case: Please refer to [RFC5920 <https://tools.ietf.org/html/rfc5920>] for details on security threats; defensive techniques; monitoring, detection, and reporting of security attacks; and requirements. Would this solve the issue? Thanks Daniele *From:* Alvaro Retana [mailto:aretana.ietf@gmail.com] *Sent:* giovedì 12 ottobre 2017 18:40 *To:* Yemin (Amy) <amy.yemin@huawei.com> *Cc:* The IESG <iesg@ietf.org>; draft-ietf-ccamp-ospf-availability-extension@ietf.org; Fatai Zhang < zhangfatai@huawei.com>; ccamp-chairs@ietf.org; ccamp@ietf.org *Subject:* Re: Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT) On Wed, Oct 11, 2017 at 10:48 PM, Yemin (Amy) <amy.yemin@huawei.com> wrote: Amy: Hi! 3) Where is this signaling defined? How does a node know that others support the Availability ISCD/LSA? The Interface Switching Capability Descriptor (ISCD) allows routing protocols such as OSPF and ISIS to carry technology specific information in the Switching Capability-specific information (SCSI) field. If a node received the Availability in the ISCD, it knows that the sender support Availability. Please add something like that, or point to the appropriate document. 4) Security Considerations, how about change the text as following: This document extends [RFC4203]. As with [RFC4203], it specifies the content of an Opaque LSAs in OSPFv2. As Opaque LSAs are not used for Shortest Path First (SPF) computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with GMPLS TE LSAs may have an impact on the ability to set up connections in the underlying data plane network. Mechanisms such as [RFC2154] and [RFC5304] to protect the transmission of this information are suggested. As the additional availability information may represent information that an operator may wish to keep private, consideration should be given to securing this information. [RFC3630] notes that the security mechanisms described in [RFC2328] apply to Opaque LSAs carried in OSPFv2. An analysis of the security of OSPF is provided in [RFC6863] and applies to the extensions to OSPF as described in this document. Any new mechanisms developed to protect the transmission of information carried in Opaque LSAs will also automatically protect the extensions defined in this document. The text above (1) still says that the extensions have no direct effect on IP routing, and (2) don't address that threat. I think that the threat with tampering may not just impact the ability to set up a connection, but it may cause routing not to be correct: use a congested path or follow a path with not enough bw, etc.. It shouldn't result in 100% lost traffic, but the routing could definitely be suboptimal. Thanks! Alvaro.
- [CCAMP] Alvaro Retana's No Objection on draft-iet… Alvaro Retana
- Re: [CCAMP] Alvaro Retana's No Objection on draft… Yemin (Amy)
- Re: [CCAMP] Alvaro Retana's No Objection on draft… Alvaro Retana
- Re: [CCAMP] Alvaro Retana's No Objection on draft… Daniele Ceccarelli
- Re: [CCAMP] Alvaro Retana's No Objection on draft… Daniele Ceccarelli
- Re: [CCAMP] Alvaro Retana's No Objection on draft… Alvaro Retana
- Re: [CCAMP] Alvaro Retana's No Objection on draft… BRUNGARD, DEBORAH A
- Re: [CCAMP] Alvaro Retana's No Objection on draft… Alvaro Retana
- Re: [CCAMP] Alvaro Retana's No Objection on draft… Yemin (Amy)