Subject: Re: [Isms] Thoughts on Encapsulation

From: "Khanh Nguyen \(khanhvn\)" <[email-masked]>
Date: Wed, 18 May 2005 18:57:54 -0700

It has been a couple of weeks since we decided to use EK.  What should
we do next?  Sam gave some thoughts about 3 choices of transport
encapsulation: TLS, SSH, and DTLS, and our recent 
discussions seem to indicate a consensus that we may need more than one
(to support both TCP and UDP.)

Assume that we pick TLS and DTLS (correct me if that's a wrong
assumption:), then I guess the next step in terms of architectural
decisions will be about authentication.  There are a few options that
have been raised:

1. Certificate (for server auth) + SASL (for client)
2. Mutual authentication using Kerberos
3. Mutual auth using PSK/LPSK (via SASL, TLS-SRP, SNMP PDU, etc.)
...

So should we start to do some evaluation of these options to find what's
most suitable for SNMP auth?  We may end up selecting more than one
method, e.g. one mandatory and a couple of optional ones... 

Khanh

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 May 2005 09:32:13 +0200

On Wed, May 18, 2005 at 06:57:54PM -0700, Khanh Nguyen (khanhvn) wrote:

> assumption:) [...]

I would not drop ssh. Besides insecure telnet, ssh is _the_ protocol to 
access CLIs and netconf also mandates the support of ssh.

The other option of course would be to define a netconf extension that
effectively tunnels SNMP like requests through netconf. So on the box,
you would just process an SNMP like <getnext/> rpc by mapping it on
the local SNMP instrumentation and on the manager side you might be
be able to provide an API which is similar to your existing SNMP API
and then at the end things run over netconf's transport (whatever
you choose). Now such ideas are of course clearly out of the scope
of the charter of this WG. ;-)

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 May 2005 10:16:17 +0200

Juergen,

[just a terminology note- in this message SNMP means the content above 
L3 that would be tunneled, except where noted(*).]

A few of us are currently thinking about a BEEP profile for SNMP.  Our 
current thoughts are to continue to use binary format, however.  This 
allows for additional code reuse and compact data structures.  However, 
one could specify profiles for both ASN.1 and an XML schema.  That 
having been said, I prefer a single approach to begin with to improve 
chances of interoperability.

Whether this is tied to NETCONF or not is an interesting question.  It 
would be REALLY nice for SNMP & NETCONF to share the same security 
context.  Doing so means that one would need to adapt to the other as 
far as what the securityName is, for instance.

As to whether to use the same port, my first consideration is whether a 
firewall administrator doing port blocking would want to block this form 
of SNMP(*) apart from NETCONF.  I think the answer is no.  However...

My next consideration is whether it is reasonable to have SNMP depend on 
NETCONF.  From a BEEP standpoint, if you're sharing the same TCP 
connection, either at the initial greeting, or the greeting after TLS is 
established, you must announce all allowed profiles.  Once you're there 
you need to announce one or more SNMP profiles because BEEP doesn't 
allow for a repeat of the greeting.  The only other option would be to 
incorporate this form of SNMP into NETCONF base protocol semantics, and 
quite frankly pragmatically I'm not a fan.  It sounds like chances of 
getting both done reduce as a product of each other.

There's a final consideration about how well the flow control in BEEP 
will be able to sustain / support both uses.  Here I'm inclined to think 
that it's sufficient, but I'm not firmly convinced.

Therefore I'd suggest that it should be possible to share a BEEP 
connection between NETCONF and SNMP but not required.  In order for me 
to say this I have to believe that interoperability will not be 
impacted.  I don't think it will be.  Am I wrong?

Thoughts?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 May 2005 10:17:08 +0200

> (to support both TCP and UDP.)

For interoperability's sake I strongly suggest that we add a single 
mechanism.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 May 2005 10:34:54 +0200

> far as what the securityName is, for instance.

You can look at this in different ways. You can either have a netconf
extension that basically allows you to access SNMP instrumentation 
using some new netconf primitives. You can strike for primitives that
can map to typical SNMP APIs so you can port management apps by relinking
them. Alternatively, you can provide new primitives (such as get-table)
which can then be supported more efficiently but require new manager
code to be used. A completely different approach is to just map the
SNMP data models into NETCONF data models and simply use netconf
primitives to access them. Again, requires new manager code. Another
option would be to just harmonize the transports so that you can
us the same security context between SNMP and NETCONF. All these
approaches have pros and cons and I have no opinion yet what the
right thing to do would be (also depends on how successful you expect
NETCONF to be).

Personally, I am not convinced by BEEP mappings. BEEP is a great piece
of engineering work but it seems that outside some core BEEPers in the
IETF nobody cares about it. This is quite different from ssh which is
very widely deployed and used. [But this is just my personal opinion
and there is probably little value in discussing opinions.]

/js

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 19 May 2005 08:53:56 -0700

>>>>> On Thu, 19 May 2005 09:32:13 +0200, Juergen Schoenwaelder <[email-masked]> said:

Juergen> The other option of course would be to define a netconf
Juergen> extension that effectively tunnels SNMP like requests through
Juergen> netconf.

I've argued for a long time that netconf needs to deal with management
too because doing 2 protocols for management is insane.  However, I'd
be very strongly opposed to having SNMP messages require netconf to be
sent under ISMS.  You're suddenly requiring boxes to speak XML when
they haven't necessarily ever before.  That's an overhead that doesn't
justify the benefits even remotely, IMHO.  Assuming that netconf is
going to take off is a very questionable assumption at this point
(don't get me wrong, I hope it is used, but I'm not going to bet
another protocol on the burdens that it imposes).

[note: for those that say HTTP interfaces require XML support, they
don't.  They require code that can generate XML-like structures though
not necessarily compliant (eg, bad-HTML).  More importantly, however,
Web servers on boxes don't have to *parse* XML which is where the
impact is.  Form data and the like is not sent in XML form.]

-- 
Wes Hardaker
Sparta, Inc.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 May 2005 11:01:33 -0400

>>>>> "Khanh" == Khanh Nguyen (khanhvn) <[email-masked]> writes:

    Khanh> It has been a couple of weeks since we decided to use EK.
    Khanh> What should we do next?  Sam gave some thoughts about 3
    Khanh> choices of transport encapsulation: TLS, SSH, and DTLS, and
    Khanh> our recent discussions seem to indicate a consensus that we
    Khanh> may need more than one (to support both TCP and UDP.)

    Khanh> Assume that we pick TLS and DTLS (correct me if that's a
    Khanh> wrong assumption:), then I guess the next step in terms of
    Khanh> architectural decisions will be about authentication.
    Khanh> There are a few options that have been raised:

    Khanh> 1. Certificate (for server auth) + SASL (for client)

That's certainly not what I said.  I said certificate+SASL.  Certs are
normally used for servers; SASL for clients.  However you should
support all the combinations if you go this route.

    Khanh> 
    Khanh> 2. Mutual authentication using Kerberos 

You should not directly use Kerberos unless you explain why SASL and
SSH fail to meet your needs.  Both of these approaches get you
reasonable Kerberos support.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 May 2005 09:02:16 -0700

Eliot Lear wrote:

This is an interesting thread.
It will be difficult to sort out the possibilities without
answered a question we used to ask a lot in the IETF:

What problem are you solving here?

There are many ways to look at the "can't get there from here" problem.
They usually depend on where you're standing at the time.  Juergen
already pointed out some of possibilities. 

I don't see the advantage of a shared BEEP connection between SNMP and
NETCONF entities, as opposed to separate connections using the same
security profile.

I can't imagine a "SNMP over NETCONF" initiative going very far in the
standards process.  SMIv2 data converted to XML encoding maybe.

Andy

> allows for additional code reuse and compact data structures.  
> However, one could specify profiles for both ASN.1 and an XML schema.  
> That having been said, I prefer a single approach to begin with to 
> improve chances of interoperability.
>
> As to whether to use the same port, my first consideration is whether 
> a firewall administrator doing port blocking would want to block this 
> form of SNMP(*) apart from NETCONF.  I think the answer is no.  
> However...
>
> My next consideration is whether it is reasonable to have SNMP depend 
> on NETCONF.  From a BEEP standpoint, if you're sharing the same TCP 
> connection, either at the initial greeting, or the greeting after TLS 
> is established, you must announce all allowed profiles.  Once you're 
> there you need to announce one or more SNMP profiles because BEEP 
> doesn't allow for a repeat of the greeting.  The only other option 
> would be to incorporate this form of SNMP into NETCONF base protocol 
> semantics, and quite frankly pragmatically I'm not a fan.  It sounds 
> like chances of getting both done reduce as a product of each other.
>
> will be able to sustain / support both uses.  Here I'm inclined to 
> think that it's sufficient, but I'm not firmly convinced.
>
>>> encapsulation: TLS, SSH, and DTLS, and our recent discussions seem 
>>> to indicate a consensus that we may need more than one
>> I would not drop ssh. Besides insecure telnet, ssh is _the_ protocol 
>> to access CLIs and netconf also mandates the support of ssh.
>>

---

From: Kaushik Narayan <[email-masked]>
Date: Fri, 20 May 2005 16:45:58 -0700

Hi Andy,

There could be benefits to sharing a BEEP connection between SNMPv3
and NETCONF (and potentially Secure Syslog) especially since SNMPv3
will be able to re-use a long lived channel between the management
systems and managed entities and save the cost of the TLS exchange
and connection state that would required to be maintained in case of
an independent connection for SNMP.

regards,
   kaushik!

At 09:02 AM 5/19/2005, Andy Bierman wrote:
>>[just a terminology note- in this message SNMP means the content above L3 
>>that would be tunneled, except where noted(*).]
>>
>>context.  Doing so means that one would need to adapt to the other as far 
>>as what the securityName is, for instance.
>>
>>you need to announce one or more SNMP profiles because BEEP doesn't allow 
>>for a repeat of the greeting.  The only other option would be to 
>>connection between NETCONF and SNMP but not required.  In order for me to 
>>say this I have to believe that interoperability will not be impacted.  I 
>>don't think it will be.  Am I wrong?
>>
>>Thoughts?
>>
>>Eliot
>>
>>>>encapsulation: TLS, SSH, and DTLS, and our recent discussions seem to 
>>>>indicate a consensus that we may need more than one