Re: [Softwires] Ops-dir review of draft-ietf-softwire-mesh-framework-05
Eric Rosen <erosen@cisco.com> Thu, 18 December 2008 20:34 UTC
Return-Path: <softwires-bounces@ietf.org>
X-Original-To: softwires-archive@megatron.ietf.org
Delivered-To: ietfarch-softwires-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF14528C122; Thu, 18 Dec 2008 12:34:36 -0800 (PST)
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32E928C122; Thu, 18 Dec 2008 12:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.124
X-Spam-Level:
X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5y-HFyoG0ZMF; Thu, 18 Dec 2008 12:34:34 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5F63428C11E; Thu, 18 Dec 2008 12:34:34 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.36,245,1228089600"; d="scan'208";a="31488250"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Dec 2008 20:34:26 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mBIKYQZl032400; Thu, 18 Dec 2008 15:34:26 -0500
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mBIKYQ11020634; Thu, 18 Dec 2008 20:34:26 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id mBIKYC6V026602; Thu, 18 Dec 2008 15:34:20 -0500
To: Pekka Savola <pekkas@netcore.fi>
In-reply-to: Your message of Wed, 17 Dec 2008 12:55:07 +0200. <alpine.LRH.2.00.0812171250350.4798@netcore.fi>
Date: Thu, 18 Dec 2008 15:34:12 -0500
Message-ID: <26601.1229632452@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6792; t=1229632466; x=1230496466; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20<erosen@cisco.com> |Subject:=20Re=3A=20Ops-dir=20review=20of=20draft-ietf-soft wire-mesh-framework-05=20 |Sender:=20 |To:=20Pekka=20Savola=20<pekkas@netcore.fi>; bh=NoiXmjXs1+gUdUiSvrvI7kFxOaT5860Xs8cnEhGzB5k=; b=HmmgwDtM7TtaCpwXNnRIn90Sn5yG6nr8LPi7x1TirhA0mXkJP8GI01uSkR dW3moY/Xf+s2wuFdmkTEScPjfeaLYOOyZWqjO6nS+IPxKd8BF726WYIl5hpO fImCeuqKzx;
Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: softwire-ads@tools.ietf.org, softwires@ietf.org, ops-dir@ietf.org, softwire-chairs@tools.ietf.org, draft-ietf-softwire-mesh-framework@tools.ietf.org
Subject: Re: [Softwires] Ops-dir review of draft-ietf-softwire-mesh-framework-05
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: erosen@cisco.com
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: softwires-bounces@ietf.org
Errors-To: softwires-bounces@ietf.org
> My main concern here is with the O&M implication of dynamically > created and used softwires, which do not run any routing protocol and > there is no IETF protocol or management framework which could be used > to verify the correct operation of these tunnels. In fact, we have over a decade of experience with softwires, implemented as MPLS tunnels. We also have many years of experience with softwires implemented as L2TPv3 tunnels, and I believe there are also deployments of softwires implemented as GRE tunnels. So it's a little late to claim that these constructs pose insuperable management difficulties. All that's really new here is that the framework for signaling the tunnels and for determining which packets get tunneled has been stated in a general way, and the use of softwires is discussed in the context of a v6/v4 Internet, rather than in the context of L3VPN. The application of OAM to softwires (particularly when realized as MPLS LSPs) has been quite extensively discussed over the years and I don't think anything new needs to be mandated by the framework document. > In S 5 (this is also bordering on architectural issue): This leads to the following softwires deployment restriction: if a BGP Capability is defined for the case in which an E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST advertise that capability. > ... is there any way an implementation could verify if this deployment > restriction holds or not? I don't think a service provider with an I-IP core would start offering E-IP transit service unless all its AFBRs were capable of providing the service. This not only includes having the appropriate BGP capabilities, but also the appropriate hardware/software capabilities to do the encapsulation and decapsulation, support for E-IP and I-IP on appropriate interfaces, etc. One could imagine configuring the BGP speakers (including route reflectors) so that IBGP connections are not accepted unless some particular set of BGP capabilities are advertised, but that's only one small piece of the overall set of deployment requirements. > The document does not describe MTU and fragmentation/reassembly issues in > the core network at all. In this kind of service my assumption is that you > need to support 1500B packets at ingress when DF-bit is set or the packet is > IPv6. Discussion in RFC4459 seems applicable here. The operational > solution to this problem is the requirement to provision the core network > with larger MTUs so that all 1500B+encapsulation overhead can be supported > throughout the core. This needs to be discussed in the text. This is a fair point. We should state a requirement that the core be able to support handle, without fragmentation, the result of encapsulating "maximum size" E-IP packets. > At some point, a client might want to upgrade to dual stack. Then, > client-interface may use both E-IP and I-IP. This solution should be > applicable then as well Depending on policy, one might or might not want to do, e.g., v6/v6 or v4/v4 encapsulation. However, covering these cases is not within the scope of the WG charter. > I.e., the longest-prefix matching is no longer sufficient with > softwires (i.e.: when deciding whether a packet to a particular E-IP > destination prefix should be tunneled through a softwire or forwarded > natively). I'm not sure what made you think that longest-prefix matching is not sufficient. > Basically what you have in AFBR's is BGP routing table with E-IP prefixes > with I-IP nexthops (and these I-IP nexthops are populated using IGP through > physical interfaces), and you can't associate I-IP nexthops with softwires > tunnel interface(s) because the next-hops must use BGP over the physical > network. > If I interpret this correctly, this is a substantial difference in the > forwarding paradigm and requirements, and should be more clearly described. > I wonder, how you would go about implementing this, in any case? This forwarding paradigm has been implemented and deployed since about 1997, and you can find many implementations where packets are sent through tunnels (whether MPLS, L2TPv3, or GRE) even though the tunnel endpoints are not routing adjacencies. > the corresponding IPv4-mapped IPv6 address for G is not a multicast > address because it does not start with FF00::/8, and I suspect as a result > all implementations will treat such a G address as a unicast address. I > guess one could fix this by standardizing a group mapping to use some > multicast prefix under ff00::/8 and encode the v4 address in the bottom > bits. Yikes, good catch. Probably we should just call out the need for such a standard to be produced. > missing standardization [in the area of tunneling multicasts] In the unicast area, most of the technology needed is already standardized or in LC, hence the framework document makes normative references. In the multicast area, the situation is different, and the framework document lays out options without making normative references to specified technology. > Have these two things [BGP next hop resolution and stacking of > encapsulations] been specified somewhere? This calls for a reference. I think "recursive route resolution" and "stacking encapsulations" are "terms of the art" which do not need to be defined in this document, but for which there is not a standard reference. > security issues > --------------- However, attacks of this sort can result in policy violations. The authorized transmitting endpoint(s) of a softwire may be following a policy according to which only certain payload packets get sent through the softwire. If unauthorized nodes are able to encapsulate the payload packets so that they arrive at the receiving endpoint looking as if they arrived from authorized nodes, then the properly authorized policies have been side-stepped. > .. I believe this could result in two kinds of attacks which could be > emphasized better (more below) Above uses "policy violations" which > may be read to refer to a policy described in Section 7. For example, > the focus of the second quoted sentence is odd -- and makes this seem like > an issue in transmitting endpoints while to me the major issue seems to be > unauthorized endpoints. The problem referred to is that if unauthorized nodes masquerade as authorized transmitting endpoints, there may be a way to side-step the authorized policies. I'm not quite sure what you are objecting to here. _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
- [Softwires] Ops-dir review of draft-ietf-softwire… Pekka Savola
- Re: [Softwires] Ops-dir review of draft-ietf-soft… Eric Rosen
- Re: [Softwires] Ops-dir review of draft-ietf-soft… Pekka Savola
- Re: [Softwires] Ops-dir review of draft-ietf-soft… Eric Rosen
- Re: [Softwires] Ops-dir review of draft-ietf-soft… Pekka Savola