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

[Stuart Mackie <[e-mail]>]

Matt,

As you have probably realized from the lack of activity on this draft, Pedro Marques has moved on and is no longer active in this area. I have been asked to take ownership and move the draft through the IETF process.

I just posted a new version of the draft which addresses the concerns raised in your email.

I have made quite a few changes for clarity in the draft, so I have described the changes that specifically address your issues in this note.

Please let me know if you have any further concerns.

Thanks

Stuart
---------------------------------------

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) [e-mail] -->
2) server-1.example -->
3) muc.example -->
4) server-2.example -->
5) [e-mail]

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.

SM>  Modified as follows:
The VPN Forwarder SHOULD use its hostname as JID, when available, or a unique IP address within the infrastructure network using its string representation. The same naming convention SHOULD be used for an End System which has an XMPP session with an external VPN Forwarder.

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., "[e-mail]").  This would disambiguate the
XMPP routing across the XMPP network.

SM> It is not, in fact, intended that End Systems communicate with the Route Server directly. There were some typos that indicated to the contrary. Figure 1 in the -05 draft was misleading since it indicated that End Systems have an XMPP session with Route Servers. The diagram has been updated as follows

                        +---------+        +--------+
                        |    RS   |--------|  BGP   |
                        +---------+        +--------+
                        /         \        /
                      XMPP         \      /
                      /             \    /
   +--------------------+            \  /
   |  End   |   VPN     |             \/
   | System | Forwarder |             /\
   +--------------------+            /  \
                      \             /    \
                      XMPP         /      \
                        \         /        \
                        +---------+        +--------+
                        |    RS   |--------|  BGP   |
                        +---------+        +--------+



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).

SM> The text now reads:
   When an external Forwarder is used, its control software MAY operate
   as an XMPP server which processes requests from end-systems and SHALL
   operate as a client of one or more End-System Route Servers.  The
   control software relays to the End-System Route Server(s) VPN
   membership stanzas it receives from the end-system.  VPN routing
   information received from the Route Server(s) SHOULD NOT be
   propagated to the end-system unless it specifically requests such
   information.  End systems MAY have sessions directly with the End-
   System Route Servers, and in this case no XMPP sessions are required
   with VPN Forwarders.

* 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.

SM> It is assumed that Route Servers contain identical routing information,
or that Routing Servers contain just the routing information required for the
VPN Forwarders that connect to them. In this second case, a Routing Server
can subscribe for routing information managed in a higher-order management
system that manages all the routing information for a domain of VPN
Forwarders. The protocol between Route Servers and such a higher-level
management could be XMPP or another convenient protocol that supports a
publish and subscribe capability.


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>

SM> This has been corrected

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

<iq type='set'
    from='[e-mail]'
    to='route-server'
    id='sub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <subscribe node='vpn-customer-name' jid='[e-mail]'/>
    <options node='vpn-customer-name' jid='[e-mail]'>
      <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>

SM>  In the external case, the VPN Forwarder has the session with the Route Server, not
the End-System, and the text has been changed to reflect this.


* 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.

SM> Within the context of this document, only VPN Forwarders are subscribing
to Route Servers.


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.
SM> Changed “message” to “stanza”, except in the section that deals with
notifications

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

SM> Change made

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

SM> Fixed

* 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.

SM> Changed to:
The VPN Forwarder SHOULD use as JID its hostname, when available, or a unique
IP address within the infrastructure network using it string representation.



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.


…………………………..

Stuart Mackie
SDN/NFV Architect

[phone]

[cid:image001.png@01D23914.C41AB720]