Subject: FW: TDomain in IPSEC-POLICY-MIB

From: "Casey Carr" <[email-masked]>
Date: Fri, 20 Apr 2001 10:47:55 -0400

Sorry, sent this to the wrong address the first time.

Casey

-----Original Message-----
From: Casey Carr [mailto:[email-masked]]
Sent: Thursday, April 19, 2001 8:53 AM
To: [email-masked]
Subject: TDomain in IPSEC-POLICY-MIB

Can someone tell me what are valid values for the "peEndpointDomain" in the
"policyEndpointToGroupTable"?   I conceptually understand why it is included
but I'm not sure which MIB defines valid Tdomain objects that relate to
transport services for IPSec.

Also, how does this MIB object map to the IPSec policy model.  I could not
find an equivalent object in either the DMTF or IETF specifications.

Casey

NetZero Platinum
No Banner Ads and Unlimited Access
Sign Up Today - Only $9.95 per month!
http://www.netzero.net

---

From: Wes Hardaker <[email-masked]>
Date: 20 Apr 2001 09:17:01 -0700

>>>>> On Fri, 20 Apr 2001 10:47:55 -0400, "Casey Carr" <[email-masked]> said:

Casey> Can someone tell me what are valid values for the
Casey> "peEndpointDomain" in the "policyEndpointToGroupTable"?  I
Casey> conceptually understand why it is included but I'm not sure
Casey> which MIB defines valid Tdomain objects that relate to
Casey> transport services for IPSec.

This certainly needs to be better described.  Only the address of the
transport domain is actually used for the endpoint.  Such that if the
snmpUDPDomain is used, the value of the peEndpointAddress should be an
appropriately specified according to the snmpUDPDomain definition, but
the port number portion of it will be ignored.

More likely, we need to define our own transport domains that are
address only to some extent.  The network address manipulation in the
MIB is certainly not trivial to understand as is and needs to be
cleaned up.

Casey> Also, how does this MIB object map to the IPSec policy model.
Casey> I could not find an equivalent object in either the DMTF or
Casey> IETF specifications.

The config-policy-model doesn't have an equivelent object.  It's
purpose is solely to take a given policy definition(s) and apply them
to "something".  That "something" in this case is fundamentally an
interface on a device.  We decided to use addresses to reference that
device instead of something like the ifIndex to better enable the use
of virtual interfaces.

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Ricky Charlet <[email-masked]>
Date: Fri, 20 Apr 2001 11:28:30 -0600

> find an equivalent object in either the DMTF or IETF specifications.

Howdy,

	TDomain is defined in rfc1903 SNMPv2-TC which refers the reader to
rfc1906 SNMPv2-TM. The possible values are:
snmpUDPDomain,
snmpCLNSDomain,
snmpCONSDomain,
snmpDDPDomain,
snmpIPXDomain.

	This choice is really a mismatch for our purposes but was just part of
us rushing to get the first draft out. Thank you for pointing to it and
getting the real discussion started.

	The question arises, what things should we support as endpoints. This
table holds enpoints for both IPsec and IKE policies. The Isakmp/IKE/doi
docs require the possible identities which may be protected are
identified by the triplit of a single port, a protocol and one of:
       ID Type                   	Value
       -------                   	-----
       RESERVED                            0
       ID_IPV4_ADDR                        1
       ID_FQDN                             2
       ID_USER_FQDN                        3
       ID_IPV4_ADDR_SUBNET                 4
       ID_IPV6_ADDR                        5
       ID_IPV6_ADDR_SUBNET                 6
       ID_IPV4_ADDR_RANGE                  7
       ID_IPV6_ADDR_RANGE                  8
       ID_DER_ASN1_DN                      9
       ID_DER_ASN1_GN                      10
       ID_KEY_ID                           11

draft-ietf-ipsec-doi-tc-mib-04.txt suggests  IpsecDoiIdentType ::=
TEXTUAL-CONVENTION. We would have to back it up with specific
definitions for each type (perhaps borrowing other textual conventions
for the specifics. How would that seem to folks?

-- 
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903

---

From: "Casey Carr" <[email-masked]>
Date: Fri, 20 Apr 2001 16:09:55 -0400

That seems reasonable to me.  The list you suggest is what I expected as
choices.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ricky Charlet
Sent: Friday, April 20, 2001 1:29 PM
To: [email-masked]
Cc: IPSec Policy WG
Subject: Re: FW: TDomain in IPSEC-POLICY-MIB

Howdy,

        This choice is really a mismatch for our purposes but was just part
of
us rushing to get the first draft out. Thank you for pointing to it and
getting the real discussion started.

        The question arises, what things should we support as endpoints.
This
table holds enpoints for both IPsec and IKE policies. The Isakmp/IKE/doi
docs require the possible identities which may be protected are
identified by the triplit of a single port, a protocol and one of:
       ID Type                          Value
       -------                          -----
       RESERVED                            0
       ID_IPV4_ADDR                        1
       ID_FQDN                             2
       ID_USER_FQDN                        3
       ID_IPV4_ADDR_SUBNET                 4
       ID_IPV6_ADDR                        5
       ID_IPV6_ADDR_SUBNET                 6
       ID_IPV4_ADDR_RANGE                  7
       ID_IPV6_ADDR_RANGE                  8
       ID_DER_ASN1_DN                      9
       ID_DER_ASN1_GN                      10
       ID_KEY_ID                           11

NetZero Platinum

---

From: Wes Hardaker <[email-masked]>
Date: 25 Apr 2001 15:40:08 -0700

>>>>> On Fri, 20 Apr 2001 11:28:30 -0600, Ricky Charlet <[email-masked]> said:

Ricky> The question arises, what things should we support as
Ricky> endpoints. This table holds enpoints for both IPsec and IKE
Ricky> policies. The Isakmp/IKE/doi docs require the possible
Ricky> identities which may be protected are identified by the triplit
Ricky> of a single port, a protocol and one of: ID Type Value
Ricky> -------                   	-----
Ricky> RESERVED                            0
Ricky> ID_IPV4_ADDR                        1
Ricky> ID_FQDN                             2
Ricky> ID_USER_FQDN                        3
Ricky> ID_IPV4_ADDR_SUBNET                 4
Ricky> ID_IPV6_ADDR                        5
Ricky> ID_IPV6_ADDR_SUBNET                 6
Ricky> ID_IPV4_ADDR_RANGE                  7
Ricky> ID_IPV6_ADDR_RANGE                  8
Ricky> ID_DER_ASN1_DN                      9
Ricky> ID_DER_ASN1_GN                      10
Ricky> ID_KEY_ID                           11

Ricky> draft-ietf-ipsec-doi-tc-mib-04.txt suggests IpsecDoiIdentType
Ricky> ::= TEXTUAL-CONVENTION. We would have to back it up with
Ricky> specific definitions for each type (perhaps borrowing other
Ricky> textual conventions for the specifics. How would that seem to
Ricky> folks?

Well, this still leaves choices in my mind.  We can:

1) use current existing TDomain style definitions, which (as pointed
   out) don't really fit our needs.

2) Use the above IpsecDoiIdentType definition, and then define how the
   value half of that is specified, um, somewhere?  Should we then
   make a IpsecDoiIdentValue TC that has an extremely long description
   clause spelling out the value formating of the OCTETSTRING that its
   made of?

3) Define our own set of 11 or so TDomains to match the above and
   continue to use TAddress as the value specifier.

There are also issues revolving around how they should be used.  In
the case of specifying an endpoint that is supposed to be singular
(open a connection to "here"), should the description clause of every
object dictate which is legal for that column and which isn't?  Or
should that definition be defined in the TC (I'd vote for the TC, but
common MIB practice is to cut-n-paste it everywhere to make sure its
visible and not missed because they didn't follow the TC reference).

I've started converting the other pieces of the MIB to use the other
TCs defined in the previously mentioned draft, but this is the case
that truly needs more thoughts.

Opinions?  I'm leaning towards #2 above I guess.

-- 
Wes Hardaker
NAI Labs
Network Associates