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.