Subject: Re: [Isms] Coming to consensus

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Jul 2005 09:41:50 +0200

On Thu, Jun 30, 2005 at 06:31:25PM -0400, Ken Hornstein wrote:

> Of these three obvious choices, the first two really want a stream transport
> (TCP).  Obviously, DTLS does not.

Can someone explain DTLS for dummies please? In particular, I would
like to know what the header size is that we have to add to SNMP
messages for DTLS. In addition, I would like to know what the effort
is to establish a DTLS session and more important how long such a
DTLS session will last or when it needs to be renewed.

/js

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Jul 2005 09:37:25 +0200

On Thu, Jun 30, 2005 at 05:06:04PM -0700, Kaushik Narayan wrote:

> We believe that BEEP should be considered as a choice
> of encapsulation protocol for ISMS. This will align us closer
> to NetConf and Secure Syslog.

The default to support netconf transport mapping as we all know is
ssh.

/js

---

From: Eliot Lear <[email-masked]>
Date: Fri, 01 Jul 2005 15:19:31 +0200

Ken,

My strong recommendation would be that if we are going to do TCP+SASL it 
should be a BEEP profile.  There are substantial ancillary benefits for 
BEEP.  For instance, the ability to multiplex streams such as NETCONF, 
secure SYSLOG, and the like come immediately to mind.  Also, it may 
simply configuration in these cases - you do one authentication 
transaction and you're done (as per the BEEP spec) for all the 
substrates.  In addition BEEP offers the ability for connection 
establishment to occur in either direction, and that has benefits with 
regard to NATs and firewalls.

In the coming weeks I will work with others to submit a viable proposal 
along these lines.

Regards,

Eliot

Ken Hornstein wrote:
> ISMS participants:
> 
> First off, my apologies for not being more active in recent weeks; the
> rest of my life keeps intruding onto IETF work.
> 
> To cut to the chase: I recently had a conference call with our sheperding
> AD, Sam Hartman, regarding the current status of ISMS.  These are the
> conclusions that we came to:
> 
> - The consensus declaration for encapsulation keying has been accepted by
>   the working group.
> 
> - There has been no clear consensus expressed by the WG participants regarding
>   a particular protocol to be used by ISMS with EK.
> 
> - There are three obvious choices (to us) for protocols to be used by ISMS:
> 
> 	TLS+SASL (more on us throwing SASL into this mix in a moment)
> 	SSH
> 	DTLS
> 
> So, the question before the ISMS WG is: which protocol do we want?  Other
> suggestions for protocols to be used are welcome; Sam and I just listed
> the ones that we saw people talking about, and ones that we thought were
> a reasonable fit for ISMS.  We would like the WG to come to a consensus
> by August.  If we had a draft by then, that would be great, but we do
> not view that as necessary.
> 
> Regarding TLS+SASL ... since the desire of ISMS is to produce a protocol
> which can leverage other authentication mechanisms, not only do you want
> to use TLS (which will provide session encryption plus the use of PK
> certificates), but you also want provisions to use SASL (or something like
> SASL I suppose, but I'm not aware of an equivalant), which supports
> a wide variety of authentication mechanisms.  This combination has been
> used by a number of protocols within the IETF community, and seems to
> be rather successful.
> 
> --Ken
>

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 1 Jul 2005 15:00:55 +0200

Juergen

DTLS is a single I-D, namely draft-rescorla-dtls-04.txt, 25pp; I am not sure if
it is standards track.

It adds epoch and sequence number, 64bit, to a TLS packet, retransmits on
timeout, may detect duplicate/replayed packets.

I would not say it introduces the concept of a session to UDP; except insofar as
one is implied by the 5-tuple of protocol, ports and IP addresses.

Tom Petch

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 01 Jul 2005 11:03:27 -0400

>to NetConf and Secure Syslog.

I'll add it to the list.

Buuuutttt .... <wg chair hat off> are you sure it makes sense?  I ask
because as I understand BEEP, it's really designed as an application
protocol layer with framing, flow control, etc etc ... which I think
might be a bit heavyweight for SNMP's needs.  Also, I'll note that BEEP
security is currently defined as TLS+SASL.

<wg chair hat on>

I guess what the working group needs to decide is (if we come to a consensus
that TLS+SASL is the way to go) does adding BEEP to the mix gain us
anything versus using TLS+SASL directly.

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 01 Jul 2005 11:17:14 -0400

>In the coming weeks I will work with others to submit a viable proposal 

I admit BEEP is not my forte, but I'm sure a draft describing how one would
do SNMP over BEEP would be extremely helpful in discussing it.

--Ken

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 01 Jul 2005 12:48:35 -0400

Just on the first part of your note:

DTLS is indeed standards track and has been approved by the IESG 
recently (this week) and is in the RFC Ed queue now.

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11289&rfc_flag=0

regards,
Lakshminath

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Jul 2005 15:05:58 -0400

Note that the WG may decide to support more than one protocol.  In
general you should do this because you believe there are environments
where all the protocols you choose are the right fit not because you
are unable to get consensus any other way.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 03 Jul 2005 15:35:17 -0400

>>>>> "Eliot" == Eliot Lear <[email-masked]> writes:

    Eliot> Ken, My strong recommendation would be that if we are going
    Eliot> to do TCP+SASL it should be a BEEP profile.  There are
    Eliot> substantial ancillary benefits for BEEP.  For instance, the
    Eliot> ability to multiplex streams such as NETCONF, secure
    Eliot> SYSLOG, and the like come immediately to mind.  Also, it
    Eliot> may simply configuration in these cases - you do one
    Eliot> authentication transaction and you're done (as per the BEEP
    Eliot> spec) for all the substrates.  In addition BEEP offers the
    Eliot> ability for connection establishment to occur in either
    Eliot> direction, and that has benefits with regard to NATs and
    Eliot> firewalls.

    Eliot> In the coming weeks I will work with others to submit a
    Eliot> viable proposal along these lines.

It is reasonably likely that the IESG will not be comfortable with the
use of multiple protocols (netconf and snmp for example) over the same
beep port.  The standard firewall considerations that apply when
deciding whether something needs its own port or can reuse port 80
apply.

--Sam

---

From: Eliot Lear <[email-masked]>
Date: Sun, 03 Jul 2005 22:38:52 +0200

Sam,

> deciding whether something needs its own port or can reuse port 80

In general I would agree with concerns about sharing a port for 
disparate uses, as discussed in RFC 3205 (BCP 56), Section 3.  However, 
I don't think we're in that situation.

The question from that document is this: does addition of one of the two 
protocols in question represent a substantially new service?  The answer 
is clearly not.  We know this because the whole point of ISMS is to 
integrate the security model with that of the rest of the administrative 
model on the device, which is what NETCONF is expected  to use.  We 
further know this because the sort of data the protocols are meant to 
carry are substantially similar.

What's more, there are two substantial benefits of combining the two:

  - Improved network performance and fairness through the use of a
    shared TCP window (Gettys / Mogul SIGCOMM 97).  This may be a
    minor or major point, but it's a bit early to say.

  - Simplified configuration and improved performance on firewalls,
    and potentially on end devices as well.  It's one less port to
    have to keep track of, and it's one less port check to have to
    process.

What's more, suppose we specify two different BEEP ports.  Arguably 
there's no way to enforce a ban on implementations sharing ports.  And 
really you have the same issue with SSH.  I wonder how many 
{anything}/ssh will really be restricted to specific ports in the 
implementations.  For this reason I don't even think it's a great idea 
to assign a separate port for netconf, but well, wrong wg.

Have a happy 4th.

Eliot

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 5 Jul 2005 07:36:46 -0400

Hi Eliot,

> carry are substantially similar.

I am a supporter of efforts to provide improved integration between
the various network mangement protocols, but I have to disagree with
your analysis here. 

I agree that a large subset of the data the two protocols are meant to
carry is substantially similar, which argues for integration of the
data models used by the two protocols. 

I disagree with your assertion that the two protocols [do not]
represent a substantially new service.  The "world tour" of data
gathering and the IAB Network Management Workshop reached the
conclusion that most operators utilize SNMP as a fault and performance
monitoring service, but not as a device configuration service. Netconf
is focused on providing a device configuration service.

NETCONF and SNMP protocols provide different services within the
network management umbrella, even though much of the data they utilize
is (or could be) common to both protocols.

David Harrington
[email-masked]