Subject: [Isms] ssh transport domain and transport address definitions

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 27 Feb 2006 21:15:30 +0100

Hi,

during the interim, we agreed that we need new TDomain/TAddress
definitions for SNMP over SSH. The security experts like to make a
distinction between SSH hostnames (the name that gets authenticated)
and DNS names or IPv4/IPv6 addresses. In the SNMP world, we are used
to deal with full transport addresses (IP address plus port number) in
the SNMP over UDP / SNMP over TCP transport mappings. So it remains a
bit unclear to me how the SSH TDomain/TAddress definitions actually
would look like.

a) [the opaque solution]

snmpSSHDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMP over SSH transport domain.
            The corresponding transport address is of type
            SnmpSSHAddress."
    ::= { snmpDomains X }

SnmpSSHAddress ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "Represents an SSH hostname."
    SYNTAX       OCTET STRING (SIZE (255))

b) [the "SMI lacks unions" solution, but we reuse TRANSPORT-ADDRESS-MIB]

snmpSSHDNSDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMP over SSH transport domain.
            The corresponding transport address is of type
            TransportAddressDns."
    ::= { snmpDomains X }

snmpSSHIPv4Domain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMP over SSH transport domain.
            The corresponding transport address is of type
            TransportAddressIPv4."
    ::= { snmpDomains Y }

snmpSSHIPv6Domain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMP over SSH transport domain.
            The corresponding transport address is of type
            TransportAddressIPv6."
    ::= { snmpDomains Z }

-- perhaps even more needed to handle zone indices?

c) [the "SMI lacks unions" solution, we prefer to be independent]

-- basically b) above except that we import TC definitions by copy
-- rather than reference

Comments?

/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: "David B Harrington" <[email-masked]>
Date: Mon, 27 Feb 2006 18:01:31 -0500

Hi,

I consdier you the expert on transportdomains. 
I was about to write you and ask hoe to do this, but here's my first
pass:

TransportAddressSSH ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1a"
    STATUS      current
    DESCRIPTION
        "Represents a hostname followed by a colon ':'
         (ASCII character 0x3A) and a port number in ASCII.
         The name SHOULD be fully qualified whenever possible.

         Values of this textual convention are not directly useable as
         transport-layer addressing information, and require runtime
         resolution. As such, applications that write them must be
         prepared for handling errors if such values are not
         supported, or cannot be resolved (if resolution occurs at the
         time of the management operation).

         The DESCRIPTION clause of TransportAddress objects that may
         have TransportAddressSSH values must fully describe how (and
         when) such names are to be resolved to IP addresses and vice
         versa.

         This textual convention SHOULD NOT be used directly in object
         definitions since it restricts addresses to a specific
format.
         However, if it is used, it MAY be used either on its own or
         in conjunction with TransportAddressType or TransportDomain
         as a pair.

         When this textual convention is used as a syntax of an
         index object, there may be issues with the limit of 128
         sub-identifiers specified in SMIv2, STD 58. In this case,
         the OBJECT-TYPE declaration MUST include a 'SIZE' clause
         to limit the number of potential instance sub-identifiers."
    SYNTAX      OCTET STRING (SIZE (1..255))

 transportDomainSSH OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "The SSH transport domain using fully qualified domain
         names. The corresponding transport address is of type
         TransportAddressSSH."
    ::= { transportDomains xxxx }
-- RFC Ed.: replace xxxx with IANA-assigned number and
--          remove this note      

An dI wasn't sure how we handle adding a new tranportType.

Dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Monday, February 27, 2006 3:16 PM
> To: [email-masked]
> Cc: Vladislav Marinov
> Subject: [Isms] ssh transport domain and transport address
definitions

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 27 Feb 2006 15:36:27 -0800

Hi -

> From: "David B Harrington" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: "'Vladislav Marinov'" <[email-masked]>
> Sent: Monday, February 27, 2006 3:01 PM
> Subject: RE: [Isms] ssh transport domain and transport address definitions
...
>          The name SHOULD be fully qualified whenever possible.
...

Presumably we mean "decimal port number".
Do we need to say anything about IDN handling?

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 28 Feb 2006 23:56:54 +0100

> Presumably we mean "decimal port number".

yes

> Do we need to say anything about IDN handling?

I assume that the value of the TC is a good old plain hostname (which
might contain an encoded IDN). In other words, I would expect
management frontends to do any IDN processing and that on the SNMP
level we only deal with ordinary lookups. Do you agree? If not, why
not?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Mar 2006 00:17:20 +0100

> I consdier you the expert on transportdomains. 

Dave, I did not receive your message directly so I grabbed it from the
mailing list archive. The snmp transport domains are a bit special...

The TransportAddress TC family (and the InetAddress TC family) is
designed to be just a discriminated union. The TransportAddress is the
union of several specific formats for IPv4/IPv6 addresses with and
without zone indexes as well as DNS names. The TransportDomain just
serves as a discriminator so that an application can cast a
TransprotAddress in a (TransportDomain, TransportAddress) pair down to
the TC indicated by the TransportDomain value.

The SNMP TDomain TC, however, associates additional semantics with the
TDomain value. In particular, transport domains for TMSMs indicate
which secure transport is being used. Since SNMP only supports
(TDomain/TAddress) to identify SNMP transport endpoints, we either

a) define separate snmpSSHTDomain values for all relevant formats for
   IPv4/IPv6 transport addresses with and without zone indexes as well
   as DNS names (and we repeat that exercise for every new TMSM), or
   we
 
b) define a single snmpSSHTDoman value and encode the transport
   endpoint into an OCTET STRING value which must be analyzed by
   implementations to figure out whether it contains a DNS name,
   or an IPv6 address with a zone identifier and port number or ...

Both options have pros and cons and I am not really sure which path to
take.

>         The name SHOULD be fully qualified whenever possible.
[...]
>    SYNTAX      OCTET STRING (SIZE (1..255))

This would pretty much require that boxes have DNS names when you use
SSH. I know environments where routers/switches do not have DNS names.
And SSH clients generally seem to work just find with IP addresses in
case there is no hostname. So I believe we should support the option
to use plain IP addresses (plus port numbers).
   
>-- RFC Ed.: replace xxxx with IANA-assigned number and

I believe this belongs below snmpDomains.

> An dI wasn't sure how we handle adding a new tranportType.

We should not mess around with TransportAddressType (in case this is
what you mean).

/js

Note that we seem to have done a bad job explaining which TDomain
value one is going to use for things not directly covered by RFC
3417. If I look at the NET-SNMP code base (5.1.4.pre3), I see:

UDP/IPv6	1.3.6.1.4.1.8072.3.3.4 
TCP/IPv4	1.3.6.1.3.91.1.1
TCP/IPv6	1.3.6.1.4.1.8072.3.3.5

I think this should be (according to RFC 3417 and RFC 3430):

UDP/IPv6	1.3.6.1.2.1.100.1.2
TCP/IPv4	1.3.6.1.2.1.100.1.5
TCP/IPv6	1.3.6.1.2.1.100.1.6

Other implementors might want to check which value they
assume/support.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 28 Feb 2006 16:07:14 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, February 28, 2006 2:56 PM
> Subject: Re: [Isms] ssh transport domain and transport address definitions
...
> > Presumably we mean "decimal port number".

It probably wouldn't hurt to say so, then.
 
...

As long as it's explicit, I'll be happy.

Randy

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 28 Feb 2006 19:11:57 -0500

Comments inline. 

> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Tuesday, February 28, 2006 7:07 PM
> To: [email-masked]

Fixed.

> As long as it's explicit, I'll be happy.

Please send wordsmithed text.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 28 Feb 2006 16:22:43 -0800

Hi -

> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, February 28, 2006 4:11 PM
...
...

When the value is a hostname, it is encoded in ASCII using the
IDNA protocol [RFC3490].

Randy