Subject: [Netconf] XMPP as transport

From: "ietfdbh" <[email-masked]>
Date: Wed, 3 Jul 2013 10:30:26 -0400

Hi Lada,

I would be interested in your analysis of how XMPP does/does not meet the
rfc6241 requirements for transport.
For example, can Netconf reliably determine if a connection is terminated,
so it knows to release locks?

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ladislav Lhotka
> Sent: Wednesday, July 03, 2013 8:55 AM
> To: Netconf
> Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-00.txt
> 
> [NETCONF list only]
> 
> Hi,
> 
> a colleague of mine proposed to define XMPP as a new transport for
> NETCONF. This would certainly solve the "calling home" issue, and may have
> other use cases, such as offloading authentication from the devices. The
idea
> is to use a (dedicated) XMPP server as a proxy to which both NETCONF
> server and client connect as XMPP clients.
> 
> Looking into XMPP spec (RFC 6120), the protocols seems to be a perfect fit
> for transporting NETCONF. Strictly speaking, it doesn't satisfy the
> requirements of 6241 in that there is no direct connection between the
> NETCONF server and client, but IMO it could work fine even without it.
> 
> So I wonder - has anybody considered this option? At least one router
> vendor (Arista) does this, though not with NETCONF.
> 
> Lada
> 
> On Jun 29, 2013, at 1:23 PM, t.petch <[email-masked]> wrote:
> 
> > ---- Original Message -----
> > From: "Kent Watsen" <[email-masked]>
> > To: "t.petch" <[email-masked]>; "Martin Bjorklund"
> > <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>
> > Sent: Friday, June 28, 2013 10:26 PM
> > On 6/26/13 1:36 PM, "t.petch" <[email-masked]> wrote:
> >
> >> Yes, that I understand.
> >>
> >> But ... the firewalls I know, at least the better ones, can look for
> > and
> >> reject PDU of protocols such as SSH, regardless of which ports the
> >> TCP connection is using.  So in that sense, a device behind a
> >> firewall that filters SSH connections still cannot be accessed.  Is
> >> this an
> > acceptable
> >> limitation?
> >
> > I would think so - this is what Juniper has been doing for almost a
> > decade now and I've never heard this raised as an issue before.
> >
> >> My other point is that I cannot see how this is a generic solution as
> >> the I-D claims.  You need something to signal that this three-way TCP
> >> handshake is for Netconf over SSH and the only parameter I can see is
> >> the port number, so this I-D cannot be used for anything else over
> >> anything else; each combination of protocols will need a different
> >> port number.
> >
> > By "generic", the draft is trying to say that the solution applied to
> > solve this problem can equally well be applied to other protocols that
> > use SSH for their transport.
> >
> > <tp>
> > OK, so it is limited to reverse SSH (as opposed to a generic call
> > home) and that is what the I-D says, so that is ok.
> >
> > But ... I would like to see a note added that the server/device must
> > be prepared to receive any SSH PDU and act appropriately and not just
> > assume it is netconf.  I am wondering if there is a Security
> > Consideration in there somewhere but cannot put my finger on one.
> >
> > Tom Petch
> >
> > </tp>
> >
> > That said, I'll just add that the port number does not have to be
> > bound to how the application might use the SSH connection.  For
> > instance, when a Junos device connects to our management server, yes,
> > it knows it can open the "netconf" subsystem, but it also knows all
> > the other subsystems it can start...and it does!  For instance, it
> > will open additional SSH channels for SFTP, notifications, packet
> > captures, etc.  It would've been easier if SSH defined a
> > subsystem-discovery mechanism, but we worked around that too.
> >
> > Thanks,
> > Kent
> >
> >
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 3 Jul 2013 18:33:40 +0200

> rfc6241 requirements for transport.

XMPP streams are secure and authenticated, typically via TLS & SASL. However, the endpoints of each stream are a XMPP server and client, so the messaging between NETCONF client and server must therefore be mediated by one or more XMPP servers, and the NETCONF parties must trust those XMPP servers.

NETCONF usernames can be derived either from JID, or just from its local part.

The "iq" stanza can be used for wrapping NETCONF RPC requests and replies, and "message" for notifications. An XMPP server must ensure in-order processing of the stanzas from a connected client (sec. 10.1 in RFC 6120).

> so it knows to release locks?

It could be done using the same mechanism that Jabber clients use for determining the presence of their peers.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 Jul 2013 10:36:41 -0700

Hi,

The "must therefore be mediated by one or more XMPP servers" part doesn't
sound too great.   Perhaps somebody should implement a prototype and compare
the performance characteristics to NETCONF/SSH or NETCONF/TLS for
multi-client provisioning. Then write an I-D explaining why we need
another NETCONF transport, and it should be XMPP.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 3 Jul 2013 19:57:44 +0200

> another NETCONF transport, and it should be XMPP.

Yes, that's my plan, unless somebody convinces me that it's a nonsense. It may be more effective than bending ssh and facing the opposition of ssh and security folks.

Performance-wise, I don't think a XMPP server could be a bottleneck. Of course, it's an extra box to care about.

Lada

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Jul 2013 14:16:10 -0600

Ahoj. ;-) David Harrington alerted me to this discussion (as author of
RFC 6120 etc.), so I've joined the list.

On 7/3/13 11:57 AM, Ladislav Lhotka wrote:
>> The "must therefore be mediated by one or more XMPP servers"
>> part doesn't sound too great.   Perhaps somebody should implement
>> a prototype and compare the performance characteristics to 
>> NETCONF/SSH or NETCONF/TLS for multi-client provisioning. Then 
>> write an I-D explaining why we need another NETCONF transport,
>> and it should be XMPP.

Pardon my ignorance of NETCONF, but it seems that even using ssh or
some other transport would require some form of mediation, no? It's
not as if NETCONF clients and servers talk to each other directly, do
they?

> Yes, that's my plan, unless somebody convinces me that it's a 
> nonsense.

I would be willing to at least advise you in that work.

> It may be more effective than bending ssh and facing the opposition
> of ssh and security folks.

I have no opinion there.

> Performance-wise, I don't think a XMPP server could be a
> bottleneck.

There are several XMPP server implementations that have been tested up
to 100,000 concurrent sessions and beyond. I don't think this should
be a problem for NETCONF.

> Of course, it's an extra box to care about.

Well, the xmpp daemon could be co-located with the NETCONF server (I'm
not clear on the usual deployment scenarios for NETCONF).

>>>> I would be interested in your analysis of how XMPP does/does 
>>>> not meet the rfc6241 requirements for transport.

I will endeavor to read RFC 6241 before long. But it might not happen
until after IETF 87.

>>> XMPP streams are secure and authenticated, typically via TLS & 
>>> SASL. However, the endpoints of each stream are a XMPP server
>>> and client, so the messaging between NETCONF client and server
>>> must therefore be mediated by one or more XMPP servers, and
>>> the NETCONF parties must trust those XMPP servers.
>>> 
>>> The "iq" stanza can be used for wrapping NETCONF RPC requests
>>> and replies, and "message" for notifications. An XMPP server
>>> must ensure in-order processing of the stanzas from a connected
>>> client (sec. 10.1 in RFC 6120).

That's all correct.

>>>> For example, can Netconf reliably determine if a connection
>>>> is terminated, so it knows to release locks?
>>> 
>>> It could be done using the same mechanism that Jabber clients
>>> use for determining the presence of their peers.

Or, if the NETCONF server is integrated with the XMPP server properly,
it might have that knowledge based on the status of connections from
clients. This, for example, is how folks are using XMPP in the
SmartGrid space (see the spec for OpenADR 2.0).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 Jul 2013 15:06:10 -0700

On Wed, Jul 3, 2013 at 1:16 PM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

A NETCONF client connects directly to a NETCONF server.
A common implementation strategy for SSH is to use OpenSSH
and have the NETCONF server be invoked as a subsystem.
The subsystem has to be a local executable, but I suppose
that could in turn open a new back-end connection to
a remote server.

I'm still not clear why I would want to tear out old code
and put in new code.  Reverse SSH seems to be a reasonable
incremental cost for NETCONF.

Andy

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJR1IaJAAoJEOoGpJErxa2pLEEP/2N2UXW/ho6HM//fPi0pu172
> MVFE6dyKbZuzw1awn4Oc1Gf6XnQvNtkRjwbMHBj59c3oyqI4RhLvBel/qT7oDNMh
> jLCKdwhyi4LuZsHlb2qV8qDQnUsTxRIW2MMAb9HLG92KKNxMogRd9DBJWWBY3udE
> BUIq4nUCfIZSUWXBPigNH9TMPw7IO/UQJh67oyVWTeVU0dLdP9eTvWvElb7aA5vD
> djYAWAcVTw+w0JTBnIJfHuXQK0IwubxPS1oND6DM03V6o1oXnyiLKg8WSsEcQ+8B
> tWliRyYNH3qo+8M/EnzM7tV8MTCnzCwcxLxiO9vi+xV0HfbOoEjCUTTA49Nk2zui
> Jhi7Knof/R5FKNZk+p6xC8c7K/uqrURz0YzeVEj8N35SkPTw0/5gx9iZLDGwgRPK
> uunLy6tBdlDg20q2ly8tkeeeR73v9Ny4mGjnKCds6zgAoQTk3YGaxAva77Uu9yls
> jG4RhKH5dX26WVpDN5AWoQv1FuVYWn1LaBdC02ucnkr88y+AZyxkvGuPIE2ZwGGp
> D7uSr4nAJzKYt1jVfGtc3aUSPfLQVv/bvE2inGPF9S3AfKdKtnNYAdk6JaRCClT8
> /XIIPnjUnHtsyMlbVyoXhqBRwMO6/StG7FzSZCCJ8M/E1szM2Lt7p5qI+rWkm12y
> gQx9QqjybIAlPgeZdqkz
> =uFhG
> -----END PGP SIGNATURE-----

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 4 Jul 2013 09:18:01 +0200

Ahoj Peter!

Thank you for your support, please see my comment inline.

> not as if NETCONF clients and servers talk to each other directly, do

NETCONF essentially assumes a TCP connection between the client and server, with additional goodies. I think the security context is also different.

> I would be willing to at least advise you in that work.

Great, thanks!

>> of ssh and security folks.

In any case, this way of using XMPP seems very natural, and most security-related issues are already handled by XMPP. Actually, XEPs 0323-0326 describe a very similar approach for "Internet of Things".

> not clear on the usual deployment scenarios for NETCONF).

In NETCONF terminology, server is the networking device that is being configured. This can be a big iron, such as a router, where running an XMPP server might be an option. But quite often, NETCONF servers run on constrained boxes where this might be difficult. Such devices could actually benefit from having an XMPP server as an external proxy that performs authentication of clients, and can also be a well-known destination for calling home.

Lada