Subject: RE: [Isms] Thoughts on Encapsulation

From: "Nelson, David" <[email-masked]>
Date: Thu, 5 May 2005 11:32:44 -0400

It seems to me that ISMS using EK is not going to closely fit into the
SNMP Security Model architecture as described in RFC 2571.  I say that
because an encapsulating security layer typically sits below the
application, (roughly) in the socket layer.  In RFC 2571 we have the
Security Model in the middle of the application protocol stack.

I would suggest, however, that we either "just get over it", and make
progress, or decide that conformity with the RFC 2571 architecture model
is of sufficient importance that we need to revisit the EK decision.

I'm suggesting that we make the decision to "just get over it" now,
because if we wait until the EK protocol selection and ISMS design phase
to deal with this conceptual issue, we run the risk of de-railing again.

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

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 May 2005 13:14:15 -0400

>>>>> "Nelson," == Nelson, David <[email-masked]> writes:

    Nelson,> It seems to me that ISMS using EK is not going to closely
    Nelson,> fit into the SNMP Security Model architecture as
    Nelson,> described in RFC 2571.  I say that because an
    Nelson,> encapsulating security layer typically sits below the
    Nelson,> application, (roughly) in the socket layer.  In RFC 2571
    Nelson,> we have the Security Model in the middle of the
    Nelson,> application protocol stack.

I'd recommend a solution like SASL external.  You add a new layer on
top of SNMP that does the encapsulation and then add a security model
that says you are using encapsulation.  If that security model is used
in a case where encapsulation is not actually happening then the
message fails the security model.

So, yes there is a new layer but you also remain consistent with (or
nearly consistent with) the security model document

--Sam

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 05 May 2005 10:59:11 -0700

Hi All,

The use of TLS to encapsulate all SNMP packets would mean that
we had an architecture discussion on keying approaches and the
result would be a new transport specification for SNMP.

The current SNMP specification provides the option to use SNMPoUDP
and SNMPoTCP, the choice of TLS as a transport will definitely have
performance implications for SNMPoUDP applications that will probably
undermine the reason for these applications to use UDP in the first place.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 5 May 2005 16:52:09 -0400

Hi David,

The current RFC for the SNMPv3 architecture is RFC3411; the RFC257x
series has been replaced by the RFC341x series. RFC3411 is about the
overall architecture, including the transport mapping, not just the
security model architecture. 

The TLSM document describes in reasonable detail an EK architecture
can fit into the RFC3411 architecture by describing the flow that
connects the transport mapping of an encapsulating transport with the
expected output of a security model, which is later used for SNMP
applications and access control. 

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Thursday, May 05, 2005 11:33 AM
> To: [email-masked]
> Subject: RE: [Isms] Thoughts on Encapsulation
>