[apps-discuss] 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: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@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: A0C8AgAuO51W/5BdJa1egzpSLEEGiFCxMoITDoFiJIVrgTk4FAEBAQEBAQGBCoQ7IwQnPQEcEAEdAjMBJwQBIA8BA4d6DgOuc5AKAQEBAQEFAQEBAQEVCYhkgWyFQjkSgmsugRsFjUKJWAGCd4FmaoIuhWmBXkqDeohfimyDcAEgAUOCEQUWgV1yAYYzgQgBAQE
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/apps-discuss/XaB-wU5wEi_vLWt4ZylLvd0xcxg>
Subject: [apps-discuss] APPDIR Review of draft-ietf-l3vpn-end-system-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-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.
- [apps-discuss] APPDIR Review of draft-ietf-l3vpn-… Matt Miller (mamille2)