[bess] APPDIR Review of draft-ietf-l3vpn-end-system-05

"Matt Miller (mamille2)" <mamille2@cisco.com> Mon, 18 January 2016 19:22 UTC

Return-Path: <mamille2@cisco.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE99B1B3C31; Mon, 18 Jan 2016 11:22:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.902
X-Spam-Level:
X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 5gNiG5tg62ll; Mon, 18 Jan 2016 11:22:05 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50111B3C32; Mon, 18 Jan 2016 11:22:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8055; q=dns/txt; s=iport; t=1453144924; x=1454354524; h=from:to:subject:date:message-id:mime-version; bh=e6IhL4AFQG4veG1fR707MHNmMKzR+edu/KdtmK2Kpt0=; b=ICsYqZop3ulADxyIiYph2YH6/UTOhnT3AQkR1UNyBHuP+/A3wI3cxBDw 9DHNlkm75dv9CmaP7w2FMzJsMD1ggV4F2NiqRmyjpWKrDypMDbXyBXUki qHl0typd5P84ZdCefznv1MEsi/4sFrxO0BxbLvKsLEuKETmlg6LfzAdBl g=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AgAuO51W/5BdJa1egzpSLEEGiFCxM?= =?us-ascii?q?oITDoFiJIVrgTk4FAEBAQEBAQGBCoQ7IwQnPQEcEAEdAjMBJwQBIA8BA4d6DgO?= =?us-ascii?q?uc5AKAQEBAQEFAQEBAQEVCYhkgWyFQjkSgmsugRsFjUKJWAGCd4FmaoIuhWmBX?= =?us-ascii?q?kqDeohfimyDcAEgAUOCEQUWgV1yAYYzgQgBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,313,1449532800"; d="asc'?scan'208";a="68141780"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2016 19:21:48 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0IJLmYD030530 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jan 2016 19:21:48 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 18 Jan 2016 13:21:47 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Mon, 18 Jan 2016 13:21:47 -0600
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: "draft-ietf-l3vpn-end-system.all@ietf.org" <draft-ietf-l3vpn-end-system.all@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Thread-Topic: APPDIR Review of draft-ietf-l3vpn-end-system-05
Thread-Index: AQHRUiV53gVx+I3+/kmFDLZltW8T5g==
Date: Mon, 18 Jan 2016 19:21:47 +0000
Message-ID: <311A5336-EC6E-40DC-B449-634225F95267@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-pgp-agent: GPGMail 2.6b2
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.81.135]
Content-Type: multipart/signed; boundary="Apple-Mail=_B81A6EB9-7439-4478-90AC-7795D60E663C"; protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/H0VbGYf6F3ch7j5RHNofKNxcmiA>
Subject: [bess] APPDIR Review of draft-ietf-l3vpn-end-system-05
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jan 2016 19:22:09 -0000

 I have been selected as the Applications in ART Directorate reviewer for
 this draft (for background on appsdir, please see
 ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.


Document: draft-ietf-l3vpn-end-system-05
Title: BGP-signaled end-system IP/VPNs
Reviewer: Matt Miller
Review Date: 2016-01-18
IETF Last Call Date: N/A
IESG Telechat Date: N/A

Summary: This draft is not ready for publication as a Proposed
Standard.

Comments:

This draft is making assumptions and design decisions that are not really
compatible with XMPP, and these should be resolved before publishing.

It's important to note XMPP is an end-to-end application routing
protocol. Clients are capable of sending data to other clients,
possibly crossing multiple server boundaries.  For example:

 1) client-a@server-1.example -->
 2) server-1.example -->
 3) muc.example -->
 4) server-2.example -->
 5) client-b@server-2.example

This document seems to make the assumption that routing is purely
between a client and its sever, which I believe has lead to design
decisions that are very problematic.

Major Issues: (All of which apply to Section 6. XMPP Signaling
Protocol)

* The addressing scheme for End Systems connecting to the external VPN
Forwarder is not explicitly documented anywhere -- the only instance I
can deduce is from the external VPN forwarded subscription example,
which seems to use a domain JID for the End System.  Without a clear
XMPP addressing scheme, properly routing stanzas across the XMPP
network and mutually authenticating TLS according to RFC 6125 (and
possibly [XEP-0178]) seem problematic to me.

If End Systems are expected to communicate directly with the Route
Server (e.g., End System addresses stanzas to the Route Server, which
the VPN Forwarder is expected to relay), the addressing scheme for all
components needs to be better defined.  For instance, the VPN Forwarder
address in XMPP could be a domain JID as it is, while the End System
address could be a bare JID derived from that VPN Forwarder's JID
(e.g., "end-system@forwarder.example";).  This would disambiguate the
XMPP routing across the XMPP network.

However, if VPN Forwarders are to act as proxies for End Systems, then
it should act as a proxy in all cases -- End Systems subscribe to
pubsub nodes on the external VPN Forwarder (which could in turn trigger
a subscribe of the VPN forwarder to the Route Server), and receive
notifications from the VPN Forwarder (which in turn are first received
by the VPN Forwarder from the Route Server).

* Using a hard-coded JID for the Route Server can be a serious problem if
there is ever a case where individual Route Servers oversee different
routing information.  If this is never the case, then a single JID for
all Route Servers is probably OK, but I think there could be problems
with properly authenticating the TLS session.  Using a different JID
for each Route Server can introduce some difficulties for End Systems
utilizing external VPN Forwarders, but I think only in the case where
the End System is expected to subscribe to the Route Server directly --
if the End System actually subscribes to the VPN Forwarder, then the
End System already knows the VPN Forwarder's JID and would not need to
determine the Route Server' JID.

Minor Issues: (all apply to Section 6. XMPP Signaling Protocol)

* The XEP-0060 PubSub subscription and unsubscription examples are
incorrect.  Specifically, the 'jid' attribute of the <subscribe/>
element is the subscriber's JID not the pubsub service, and
subscription options are encoded using Data Forms [XEP-0004].

The co-located example then is:

<iq type='set'
    from='forwarder.example'
    to='route-server'
    id='sub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <subscribe node='vpn-customer-name' jid='forwarder.example'/>
    <options node='vpn-customer-name' jid='forwarder.example'>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='vpn#instance-id'>
          <value>1</value>
        </field>
      </x>
    </options>
  </pubsub>
</iq>


The external example could be the following (if there is a single
addressing scheme):

<iq type='set'
    from='end-system@forwarder.example';
    to='route-server'
    id='sub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <subscribe node='vpn-customer-name' jid='end-system@forwarder.example'/>;
    <options node='vpn-customer-name' jid='end-system@forwarder.example'>;
      <x xmlns='jabber:x:data' type='submit'>
        <field var='vpn#vlan_id'><value>100</value></field>
      </x>
    </options>
  </pubsub>
</iq>


The unsubscribe example is then:

<iq type='set'
    from='forwarder.example'
    to='route-server'
    id='unsub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <unsubscribe node='vpn-customer-name'
                 jid='forwarder.example' />
  </pubsub>
</iq>


* Requiring pubsub notifications to always go from the Route Server to
the VPN Forwarder regardless of what entity subscribed to the pubsub
node is counter to how XEP-0060 works.  The pubsub subscribe request
specifies where the notifications are supposed to go, and the pubsub
service is expected to honor that.  See above in the addressing
discussion for some ideas of how to deal with this.


Nits:

* (Mostly in Section 6. XMPP Signaling Protocol) The document often
uses the term "message" when discussing XMPP communications. The XMPP
term of art is "stanza" not "message"; "message" has a specific
meaning in XMPP that is not in use here, and can lead to confusion
for readers of this document once they follow the references to
RFC 6120 and the various XEPs.

* In Section 1. Introduction, the use of the term XMPP should be
followed by a reference to RFC 6120.

* In Section 6. XMPP Signaling Protocol, the seventh paragraph
(immediately preceding Figure 1) has an extraneous period (.) at the
end of the last sentence.

* In Section 6. XMPP Signaling Protocol, I understood the meaning of
the following sentence:

    The VPN Forwarder SHOULD use as JID its hostname, when available,
    or an unique IP address within the infrastructure network win its
    string representation.

Regardless of how my XMPP addressing concerns are finally resolved,
please revisit this sentence.


References:

[XEP-0004]: Data Forms < http://xmpp.org/extensions/xep-0004.html >
[XEP-0030]: Service Discovery < http://xmpp.org/extensions/xep-0030.html >
[XEP-0178]: Best Practices for Use of SASL EXTERNAL with Certificates < http://xmpp.org/extensions/xep-0178.html >


--
- m&m

Matt Miller
Cisco Systems, Inc.