[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ipsp-policy-pib
On Tue, 6 May 2003, Wijnen, Bert (Bert) wrote:
> Thanks for that info. But I was asking about the PIB (not MIB)
> and specifically about the use of some INET-ADDRESS-MIB TCs.
> This doc has been on agenda for (for Informational) a while and
> basically has been OKed except for me still bitching about
> details. So I wondered if it was just me... or if my worries are
> real
I assume the document you refer to is draft-ietf-ipsp-ipsecpib-07.txt,
which I just downloaded.
> See specifically The ipSecAddressTable
>
> I am sort of too overloaded to do detailed checking on PIB
> documents. At the other hand... strange things are being
> done as far as I can tell.
OK, I've attached some quick in-line comments on the
ipSecAddressTable below. It will be interesting to see if we
complain about the same things.
//cmh
IpSecAddressEntry ::= SEQUENCE {
ipSecAddressPrid InstanceId,
ipSecAddressAddressType InetAddressType,
ipSecAddressAddrPrefixLength InetAddressPrefixLength,
ipSecAddressAddrMin InetAddress,
ipSecAddressAddrMax InetAddress,
ipSecAddressGroupId TagId
}
ipSecAddressPrid OBJECT-TYPE
SYNTAX InstanceId
STATUS current
DESCRIPTION
"An integer index that uniquely identifies an instance of this
class."
::= { ipSecAddressEntry 1 }
ipSecAddressAddressType OBJECT-TYPE
SYNTAX InetAddressType
STATUS current
DESCRIPTION
"Specifies the type of IP address.
While other types of addresses are defined in the InetAddressType
textual convention, an IP filter can only use IPv4 and IPv6
addresses directly to classify traffic. All other InetAddressTypes
require mapping to the corresponding Ipv4 or IPv6 address before
being used to classify traffic. Therefore, this object as such is
not limited to IPv4 and IPv6 addresses, i.e., it can be assigned
any of the valid values defined in the InetAddressType TC, but the
mapping of the address values to IPv4 or IPv6 addresses must be
done by the PEP at install time. "
::= { ipSecAddressEntry 2 }
-- comments:
-- What the DESCRIPTION above is saying (if I read it correctly) is
-- that the Policy Enforcement Point (PEP) has to do a DNS lookup if
-- the address type is dns(16). However, it's now clear how the rest
-- of the items in the row can be set correctly specified unless the
-- type is already know, i.e., if the name-to-address resolution is
-- already done. In other words, it's not clear why dns(16) should
-- be allowed here.
ipSecAddressAddrPrefixLength OBJECT-TYPE
SYNTAX InetAddressPrefixLength
STATUS current
DESCRIPTION
"The length of a mask for the matching of the IP address specified
by ipSecAddressAddrMin. This attribute is interpreted only if the
InetAddressType is 'ipv4', 'ipv4z', 'ipv6' or 'ipv6z'.
Masks are constructed by setting bits in sequence from the most-
significant bit downwards for ipSecAddressAddrPrefixLength bits
length. All other bits in the mask, up to the number needed to
fill the length of the address ipSecAddressAddr are cleared to
zero. A zero bit in the mask then means that the corresponding bit
in the address always matches.
In IPv4 addresses, a length of 0 indicates a match of any address;
a length of 32 indicates a match of a single host address, and a
length between 0 and 32 indicates the use of a CIDR Prefix. IPv6
is similar, except that prefix lengths range from 0..128.
When ipSecAddressAddrMax is not a zero length OCTET STRING, this
attribute MUST be ignored since a range of consecutive Internet
addresses is being specified."
::= { ipSecAddressEntry 3 }
-- comments:
-- The DESCRIPTION clause needs to specify that this is interpreted in
-- the context of ipSecAddressAddressType. It is also noted that the
-- InetAddressPrefixLength TC DESCRIPTION clause specifies that only
-- the special value 0 applies in the case of addresses of type dns(16).
-- The definition as it stands suggests that if ipSecAddressAddressType
-- is dns(16) then the PEP would have to look up ipSecAddressAddrMin and
-- determine its type in order to interpret this object. That is not
-- consistent with the InetAddressPrefixLength TC DESCRIPTION clause.
-- Also, in IPv4 addresses a length of 32 __or greater__ indicates a
-- match of a single host, per TC descr clause (similarly for IPv6.
-- Finally, the usage of ipSecAddressAddrMax to nullify the significance
-- of this object may be problematic (see comments below), and it's not
-- necessary to do that. Instead interpret this object,
-- ipSecAddressAddrMin, and ipSecAddressAddrMax as specifying a range
-- of prefixes to be matched. Set this object to 32 or 128 to make a
-- range of individual addresses; set ipSecAddressAddrMax equal to
-- ipSecAddressAddrMin to use only the "masking" capability.
ipSecAddressAddrMin OBJECT-TYPE
SYNTAX InetAddress
STATUS current
DESCRIPTION
"Specifies an IP address. If the address type is 'ipv4', 'ipv6',
'ipv4z' or 'ipv6z' then, the attribute
ipSecAddressAddrPrefixLength indicates the number of bits that are
relevant."
::= { ipSecAddressEntry 4 }
-- comments:
-- The DESCRIPTION clause needs to specify that this is interpreted in
-- the context of ipSecAddressAddressType.
ipSecAddressAddrMax OBJECT-TYPE
SYNTAX InetAddress
STATUS current
DESCRIPTION
"If a range of addresses is used then this specifies the ending
address. The type of this address must be the same as the
ipSecAddressAddrMin.
If no range is specified then this attribute MUST be a zero length
OCTET STRING. "
::= { ipSecAddressEntry 5 }
-- comments:
-- The DESCRIPTION clause needs to specify that this is interpreted in
-- the context of ipSecAddressAddressType. And if it is interpreted
-- in that context, then the use of a zero-length string to specify
-- "this object is a don't care" seems to be inconsistent with the
-- definition of the InetAddress TC. This is easily avoided by
-- instead having the value be the same as ipSecAddressAddrMin.
ipSecAddressGroupId OBJECT-TYPE
SYNTAX TagId
STATUS current
DESCRIPTION
"Specifies the group this IP address, address range or subnet
address belongs to."
::= { ipSecAddressEntry 6 }