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