Re: [CCAMP] Alvaro Retana's No Objection on draft-ietf-ccamp-ospf-availability-extension-10: (with COMMENT)
Alvaro Retana <aretana.ietf@gmail.com> Thu, 12 October 2017 16:40 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 667B7133187; Thu, 12 Oct 2017 09:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, SPF_PASS=-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 4V0ug9zEbaX6; Thu, 12 Oct 2017 09:40:22 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 799F2124B18; Thu, 12 Oct 2017 09:40:22 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id f66so9441145oib.2; Thu, 12 Oct 2017 09:40:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=deHQStkKZmMsue5Xlf+uivAnX6hHAiyqyNGDDZoQJuE=; b=WHPKmlwdpsIIcM/OuAvtYKE7gGDe3UbS1SLM7oYqWwijAJa18NKdrZLGUkM9DCPATR w5vPz6tXlNTMlR+3LwxGWnfGP5/TiH4Y+q6Qw/LdimPfkXT2XhZEV74N+dLcTvOARcAU QDSPldotflrKUeOtR6KU1138BVjHjYLgHPpWTlEk4z9NC6AjIsIZ/v7MmNxCLwSMbFDm M57IjK5FqRinXqNkoc/dUj3yKL0Sb4WdErStXsU21TlULf3iebk22ygaribA7qualbvU uxrL0rN8IT7B4qEOxEwBdHHbzB2vDut2tSMVmi8jFevJM7hRnRZ10Vn/HIbd6W/Oejjf COXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=deHQStkKZmMsue5Xlf+uivAnX6hHAiyqyNGDDZoQJuE=; b=LseR8lJ3TYQzugJXYlyYOLT+IVnRi6a53MHUGb8ARgYQIQN1nkimGbogfebg0sNdqq KhP8JWAfyrgQqdV6z6fq/2FIAgg/6dSLR0ejxF5NzzfxhySaybWQJf5yjRjKRBZmm2qR 19GzMQryrbzlKcyVavv1YkrtXPNsYcr4U/twNdNZcFa6DtwJ66G5p6tny0uEvWdfVP91 efT7VKnxgk59gSCZBP7gx69KF9THEHPllih+PtIS077mxFF8UBWnBY6kw+j90dSpy0qy vfQeg6uyP8RRd4+ElNQsTiEdXc//W/PXvX0y6vgIuCESf0rcWRUe5mXqauOHuEYI7OgN zX4Q==
X-Gm-Message-State: AMCzsaW31jC6DOMPDBCdQYb0tTgAgX3RzNcGa7Jr9cKGSMWHQEP0I2cA nDloUk/HOCFK/nwleGsRDB/W6CRsXrQgdQdkD7c=
X-Google-Smtp-Source: AOwi7QCVHcOvqt+HvIZVwCmaj/JcyVA8f9Om90YErHJUVbBpa4LZmKFSt+0Hffvhh+MwoGp2Y9ZyvrLOdg5tieeYFs0=
X-Received: by 10.202.225.195 with SMTP id y186mr1710795oig.21.1507826421763; Thu, 12 Oct 2017 09:40:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.60.90 with HTTP; Thu, 12 Oct 2017 09:40:21 -0700 (PDT)
In-Reply-To: <9C5FD3EFA72E1740A3D41BADDE0B461FC7591FFA@DGGEMA501-MBX.china.huawei.com>
References: <150766267307.13579.9907623355727477623.idtracker@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FC7591FFA@DGGEMA501-MBX.china.huawei.com>
From: Alvaro Retana <aretana.ietf@gmail.com>
Date: Thu, 12 Oct 2017 12:40:21 -0400
Message-ID: <CAMMESszqT+Tj6iVg8SBdAsmC3hkX9N7WDsMqZLo98H4H50uwPQ@mail.gmail.com>
To: "Yemin (Amy)" <amy.yemin@huawei.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-ccamp-ospf-availability-extension@ietf.org" <draft-ietf-ccamp-ospf-availability-extension@ietf.org>, Fatai Zhang <zhangfatai@huawei.com>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Content-Type: multipart/alternative; boundary="001a113d524e409519055b5c32a1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/so077zbHlK7QG9XwiCpyiHZgZ9E>
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: Thu, 12 Oct 2017 16:40:24 -0000
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)