[09:15:47] --- dbh2 has joined
[09:45:02] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[09:45:26] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Hi Dave.
[09:50:14] <dbh2> Hi
[09:51:16] <dbh2> So th ejabber logs are complete, do you want to post the agenda and the list of issues we want to reach consensus on?
[09:52:29] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Agenda for the ISMS phone conference on July 27 1. Agenda bashing 2. Call Home for SSH Main subject will be agent initiated channels for notifications. Juergen S. raised this issue in our last session. Please find his slides at <http://www3.ietf.org/proceedings/06jul/slides/isms-2.ppt> The main question to be answered is: "Is the reverse creation of an SSH session as suggested in the slides an acceptable solution for ISMS notifications? 3. Alternative approaches If call home for SSH does not work, alternatives need to be discussed. Wes listed three of them in his email from July 17: <http://www1.ietf.org/mail-archive/web/isms/current/msg02097.html>. We will have as look at all three and try to identify pros and cons for each of them. 4. Summary of technical results
[10:04:36] --- bert has joined
[10:05:31] --- pigdog has joined
[10:06:11] <bert> I have invited Sam and Dan (they are on my buddy list)
[10:06:31] <bert> who is pigdog (if I may ask)?
[10:06:42] --- hartmans has joined
[10:07:08] <j.schoenwaelder@jabber.eecs.iu-bremen.de> To summarize the alternative approaches: (1) ssh connection initiated by the NO (agent), authentication using user credentials provisioned on the agent (2) ssh connection initiated by the NO (agent), authentication using host keys (readily available on the agent) (3) ssh connection initiated by the NR (manager), authentication using normal user credentials (nothing needs to be provisioned) The perhaps impossible but interesing solution would be: (0) ssh connection initiated by the NO (agent), authentication using normal user credentials from the NR side (nothing needs to be provisioned)
[10:07:43] <pigdog> juergen s., are you dialed in?
[10:07:44] --- dromasca has joined
[10:07:46] --- Juergen Q. has joined
[10:07:51] <bert> so pigdog is Eliot
[10:07:56] <pigdog> yep
[10:08:16] <bert> Hi Juergen
[10:08:24] <bert> david Perkins is dialed in
[10:08:41] <bert> Wes is dialed in
[10:08:46] <bert> Jeff is dialed in
[10:11:16] <bert> where do we find the slides from juergen again?
[10:11:28] <Juergen Q.> 2. Call Home for SSH Main subject will be agent initiated channels for notifications. Juergen S. raised this issue in our last session. Please find his slides at <http://www3.ietf.org/proceedings/06jul/slides/isms-2.ppt> The main question to be answered is: "Is the reverse creation of an SSH session as suggested in the slides an acceptable solution for ISMS notifications? 3. Alternative approaches If call home for SSH does not work, alternatives need to be discussed. Wes listed three of them in his email from July 17: <http://www1.ietf.org/mail-archive/web/isms/current/msg02097.html>. We will have as look at all three and try to identify pros and cons for each of them.
[10:11:38] --- Juergen Q. has left
[10:12:04] --- Juergen Q. has joined
[10:14:53] <j.schoenwaelder@jabber.eecs.iu-bremen.de> is there any way to arrange things such that a notification recipient authenticates against a notification originator and the notification originator initiates somehow the connection.
[10:16:47] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sam: two issues (1) where are credentials provisioned? (2) access control impact?
[10:19:38] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Wes: Once you send a notification, you pretty much know the target. Access control then filters based on the identity of the receiver.
[10:20:25] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Bert: What if the NO simply sends a UDP packet and this causes the NR to initiate a sesseion.
[10:21:29] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sam: Not only denial of service; may allow attackers to fool managers to connect to devices they shouolt not connect to.
[10:21:53] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DaveP: Sounds fragile
[10:21:59] <bert> right. And that UDP packet contains only the userName (or securityName)
[10:22:07] <bert> It does not contain any password.
[10:22:46] <bert> I see the DoS issue (that exists in current SNMP too I think, just sending traps/notifications)
[10:23:00] <bert> So I do not see the problem with the password.
[10:24:08] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sam: NO needs to do the access control; given that if you do auth at SSH level and NO is SSH client, then the ACLs need to be different.
[10:26:02] <bert> Why does NO need o be the SSH client?
[10:26:24] <bert> Maybe we should just allow TRAPv2 in SNMP over SSH and not INFORM
[10:26:45] <bert> for TRAPv2, the authoritative (server) side is the agent (i.e. the NO)
[10:26:45] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sam: You need to know the transport address and security name when a NO sends a notification
[10:30:38] <j.schoenwaelder@jabber.eecs.iu-bremen.de> There is a difference between the UDP case where I can tell a manager to establish a connection to some other agent. The TCP turn before SSH starts seems to avoid this issue.
[10:31:40] --- dromasca has left: Disconnected
[10:33:28] <j.schoenwaelder@jabber.eecs.iu-bremen.de> I am lost - what is impossible here? What are you talking about?
[10:33:57] --- dromasca has joined
[10:35:24] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DaveP: What is the transport address? If it includes a port number, than pointing to a NR might be difficult in the transport tables.
[10:36:43] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DaveH: There was a proposal to have a TDomain which has host names.
[10:37:19] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Jeff: Not sure whether it includes a port or whether the port might be ignored or ...
[10:38:32] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Discussion about session reuse.
[10:40:44] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Wes: once a session is open, deciding how to use it is interesting part. One is to have config information. Some of that information may be automatically populated.
[10:41:51] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Wes: The details are in the target table.
[10:43:02] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Wes: Out of that comes a security name, a target, and a message to be send.
[10:43:39] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Wes: We might have to define a specific TDomain which points to an existing session.
[10:44:45] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sam: probably good if you have a session, but not enough information when you have to create a session.
[10:46:08] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Wes: I don't think you want to match to multiple SSH sessions.
[10:47:57] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Wes: Limit scope since it makes a difference depending on which party opens the connection.
[10:49:23] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sam: Want an abstraction, adding a target dynamically has security issues.
[10:50:01] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sam: Deployments with little or no ACLs may be problematic.
[10:50:25] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DaveH: SNMP forces access control.
[10:51:56] --- hartmans has left: Replaced by new connection
[10:52:10] --- hartmans has joined
[10:52:34] <hartmans> I will have to leave shortly.
[10:53:32] <j.schoenwaelder@jabber.eecs.iu-bremen.de> There are use cases where we have very short lived notification originators (programs forking snmptrap which just ships the notification).
[10:54:40] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sam: How long do we have to wait for an incoming connection?
[10:55:24] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Wes: Sending a UDP packet first is insane.
[10:56:40] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Wes: Out-of-band signalling should be out of scope.
[10:57:08] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Sam: I am not that much concerned about security aspects.
[10:58:08] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DaveH: Use a USM without authentication to cause initiation of a session.
[10:58:11] <hartmans> I don't like the UDP approach, but I think it is something the WG could do if it likes.
[10:58:42] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Eliot: Lots of NAT traversal issues.
[11:02:03] --- hartmans has left
[11:03:04] --- dromasca has left: Disconnected
[11:03:38] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DaveH: two discussions (a) how do we get the transport to work, (b) how do we get authentication and access control to work.
[11:04:11] <bert> So Eliot, to come back to the call-home.
[11:04:37] <bert> If I understood that issue correctly, then you were telling us (a while back) that the AGENT MUST be able to setup/initiate
[11:04:53] <bert> the connection, because an manager would not be able to do so (NAT translation).
[11:04:54] <pigdog> to be clear...
[11:05:17] <pigdog> my absolute nirvana would be that either side could initiate for either purpose.
[11:05:31] <pigdog> however, "Call Home" says that the agent initiates for both.
[11:05:32] <bert> The out-of-band UDP packet would let the manager know how to contact it. That is the idea, I think
[11:05:33] <j.schoenwaelder@jabber.eecs.iu-bremen.de> DaveH: Needs to figure out where EoPs need modification.
[11:06:02] <bert> but now you say that the agent can not get through the nAT (calling home) either
[11:06:10] <pigdog> i 'll hang on for a moment
[11:06:20] <pigdog> for UDP
[11:06:31] <bert> and not for TCP?
[11:06:35] <bert> Why is that?
[11:06:42] <pigdog> the best approach would be a single connection for everything. this limits the fragility.
[11:06:47] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Bert, the agent may not be aware of the firewalls on the path between the agent and the manager.
[11:06:49] <bert> What is the reason that so many NATs prohibit UDP?
[11:06:57] <pigdog> think of it in terms of a simple access list in a firewall
[11:07:08] <pigdog> and now you need two entries instead of one
[11:07:24] <pigdog> in addition to that, because UDP has no notion of session, many firewalls want to be stateful
[11:07:38] <j.schoenwaelder@jabber.eecs.iu-bremen.de> NATs monitor TCP connection setup exchanges and learn what needs to be done. With UDP, there is no way to learn this without perhaps understanding the protocol running over UDP.
[11:07:38] <pigdog> and so that means that they want some application logic
[11:07:50] <pigdog> right
[11:08:13] <bert> I thought they would just keep state of "UDP sessions" for some (short) amount of time.
[11:08:29] <pigdog> furthermore, most firewalls - in a deployment sense- have to let TCP go outbound. in general they don't have to let *most* UDP go through
[11:08:41] <bert> And I am not worried about all sorts of the most cheap NATs. Even the one I have at home I believe remembers "UDP sessions"
[11:08:50] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Some do, some don't. They surely do not expect that a UDP message is somehow related to a subsequent TCP stream.
[11:09:12] <pigdog> here is a little test. see if you find someone in your company with a Mac and ask them to create a voice session with someone outside the firewall. in all likelihood it would fail
[11:09:34] <pigdog> and so in all likelihood, SNMPv3 would fail as well
[11:09:43] <bert> Aha... now I got it... they cannot/wil not link a UDP translated address to an incoming TCP stream. I can see that that may not be
[11:09:46] <bert> widely supported.
[11:09:48] <j.schoenwaelder@jabber.eecs.iu-bremen.de> That actually works for me (because my Voice apps know how to use STUN et. al.)
[11:10:19] --- Juergen Q. has left
[11:10:27] <pigdog> and STUN is fine when for the case where there is just a NAT and not a firewall.
[11:10:33] <pigdog> or the firewall is liberal about UDP (rare)
[11:10:51] <pigdog> one approach I heard early on was that we should use STUN.
[11:11:07] <bert> Well, security does not come fro free. So I'd tell customers: You want security: this is what you need to buy/configure/do
[11:11:29] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Thinking loud: Would it be an option to have an SNMP/SSH solution which only works for established sessions and to leave the details how such sessions are established out? This is basically what netconf does - they just say magically the manager knows how and when to setup a session and to subscribe to an notification stream.
[11:12:07] <pigdog> I think there needs to be enough there so that if someone wanted to configure such a connection out of band it would work
[11:12:30] <j.schoenwaelder@jabber.eecs.iu-bremen.de> What do you mean by configure out of band?
[11:12:32] <pigdog> so, bert, your notion of out of band configuration is a good one. just UDP causes a problem or two.
[11:13:08] <pigdog> juergen: if I could configure my SSH subsystem to create a connection with the notification receiver...
[11:13:16] <j.schoenwaelder@jabber.eecs.iu-bremen.de> You can ship the UDP trap over TCP but then security folks tell you that you can't reuse the same TCP connection and you are back to where you started.
[11:13:40] <pigdog> when i say configure, i mean in nonvolatile stoarge
[11:14:31] <bert> So if you do an outgoing TCP connection, does the NAT not remember the IP address when another incomming TCP connection arrives?
[11:15:00] <j.schoenwaelder@jabber.eecs.iu-bremen.de> In netconf, it is the manager who knows what needs to be done. A device won't deliver notifications via netconf until the manager has created session and subscribed to the event stream.
[11:15:11] <pigdog> well, define "remember". yes, it has a translation table.
[11:15:18] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Bert: The NAT cleans up when it sees the TCP connection teardown.
[11:15:26] <pigdog> j: right
[11:15:45] <pigdog> j: for netconf,
[11:15:58] <bert> So it is a matter of specing out the the outgoing TCP connection needs to stay up for say x seconds/minutes?
[11:16:04] <pigdog> if you use BEEP, the agent can connect to the manager
[11:16:22] <pigdog> b: yes.
[11:16:28] <bert> So you would spec that the manager breaks the TCP connection from the agent AFTER it has setup an SSH connection
[11:16:32] <pigdog> b: that would be the sort of information you would want in the table.
[11:16:34] <j.schoenwaelder@jabber.eecs.iu-bremen.de> Oh, I forgot about BEEP.
[11:16:37] <pigdog> (configuration)
[11:16:39] <bert> and so the agent never breaks the TCP connection itself
[11:17:32] <bert> would that work?
[11:17:44] <pigdog> yes, i think it would
[11:17:56] <pigdog> but i have to admit I may not have the whole thing in my head
[11:18:04] <pigdog> i could envision either side breaking a connection
[11:18:14] <bert> so: agent connects over TCP, managers setsup SSH, then manager breaks the TCP connection it got from agent
[11:18:15] <pigdog> again, it would depend on configuration information
[11:18:40] <pigdog> no, sorry. that's not what I mean
[11:19:18] <pigdog> once the agent has the connection, we need to make that work. and here's my point, and I think Wes' as well: once you have a communication path you should maintain it and use it because you may not be able to get the communication going in the reverse direction
[11:19:37] <bert> If you tell (spcify) that agent does not break/close TCP connection (or maybe only after 5 minutes if it is still there), then the TCP connection stays up till the managers has completed ssh connection, and only then does manager close the TCP connection. So th NAT translation table stays in tact as long as needed automagically I think.
[11:19:53] <pigdog> in another context, this is why HTTP is used for everything
[11:20:33] <pigdog> sorry- i may have lost the plot on your last note. unfortunately, my time is up. all the best...
[11:20:47] --- pigdog has left
[11:21:12] <bert> Juergen, do you think that the TCP our of band works as I describe above? I think so.
[11:21:16] <j.schoenwaelder@jabber.eecs.iu-bremen.de> But then the manager would have to initiate a new TCP connection with exactly the same IP addresses and ports - basically faking a new TCP connection over the existing one. I am not sure why that should be better or more secure than just turning the connection. ;-)
[11:22:24] <bert> Why the same PORT? Does the NAT not map the ip-address.? I guess those that use PORT mapping only, they won' t. There may indeed be (many) such devices
[11:23:36] <bert> Gee... you know... this "managing networks behind NATs (i.e. with private address space) was an issue that I got bothered with back in 1989 or so.
[11:24:02] <bert> Back then I was able to handwave it away as a very specific problem, not generic enough to work on it
[11:24:13] <bert> Abd now it is still hitting us
[11:25:42] <bert> OK, signing out from here
[11:26:49] --- bert has left
[11:28:09] <j.schoenwaelder@jabber.eecs.iu-bremen.de> There are many different NAT types and this makes things complex and nasty. Many programs these days try to figure out which NAT(s) are on the path to work around them in whatever way might work. This is really a nasty subject and the best advice I think is to design application protocols that run over TCP to allow both sides to create a connection. Then you are in a pretty good shape. The only problem we have is that SSH does not like this and the enthusiasm to perhaps fix/enhance SSH seems to be rather small. So we will have to give up call home and may end up with quite some configuration complexity on the SNMP agent side, which kind of defeats the goals of ISMS. One option is to choose a solution which might not work for all SNMP use cases or to conclude that SSH might not be the right protocol for the job. I am not sure whether I mean this serious yes - but the simple fact that discussions are getting very difficult to follow since there are so many sub-issues to consider concerns me.
[11:38:29] <dbh2> SSH may not be the right protocol for our purposes. However, I am not sure what other protocol has the right characteristics either. TLS performs authentication usually at the host/server level. Client-auth can be added. Should we look at TLS? BEEP handles these issues supposedly; should we look at BEEP?
[11:40:18] <j.schoenwaelder@jabber.eecs.iu-bremen.de> I believe TLS can be used in a symmetric way, even though that is frequently not done since it does not make sense to provision certificates on clients that serve the web. But in the network management context, this might actually work out better. In general, I just have a strange feeling and perhaps this is just because it is hot and I need vacation.
[11:46:55] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left: Logged out
[15:01:51] --- dbh2 has left