Re: IPSP MIBs usage review needed

[Robert Story <ipsp-mib@xxxxxxxxxxxxxx>]

On Thu, 25 Nov 2004 10:41:33 +0100 Yacine.El_Mghazli@xxxxxxxxxx wrote:
YEF> > 7) You defined an ipiaIkeActionTable row, but not any associated
YEF> > ipiaIkeActionProposalsTable and ipiaIkeProposalTable rows.
YEF> 
YEF> this is a point we had troubles to figure out how it works.

I've just recently finished updating some graphics for the recent MIB split.
They may (or may not) help you get a grasp on the relationships between the
tables:

	http://net-policy.sourceforge.net/tutorial/mib2/index.html

YEF> our understanding is that ipiaIkeActionProposalsTable and
YEF> ipiaIkeProposalTable gives the necessary information for the Phase 2
YEF> negotiation. could you please provide us with consistent values for 
YEF> those entries (instead of xxx) ?

The spdRuleDefAction will point to a row in the ipiaIkeActionTable, which is
indexed by a name (ipiaIkeActName). For that action, the same index (name)
is used as the primary index into the ipiaIkeActionProposalsTable. The
secondary index is a priority (ipiaIkeActPropPriority), which allows ordering
of the proposals that will be sent to the peer (or accepted from the peer). The
ipiaIkeActPropName points to a row in the ipiaIkeProposalTable, which contains
the actual IKE parameters.

There is a similar hierarchy for the IPsec proposals, which are used for Phase
2 negotiations, and result in a Phase 2 SA being created, upon successful
negotiations.

YEF> > 8) pre-shared keys should be stored in the ipiaCredentialTable. The
YEF> > ipiaCredentialFilterTable is for matching incoming credentials from
YEF> > peers.
YEF> 
YEF> cannot find such a table in the IPIA MIB. are you really sure the PSK is
YEF> not stored in the ipiaCredentialFilterTable ?

The ipiaCredentialTable is in the IPSEC-IPSECACTION-MIB, and I am quite sure
it is the right table. An IKE identity would refer to the ipsaCredentialTable
for the credential to be used during negotiations. The
ipiaCredentialFilterTable would be more useful for allowing/disallowing packets
for more flexible credential types (like x.509 certificates; eg, disallowing
certs from a certain issuer).

YEF> > 9) You define IKE actions, but no IPsec actions, so I assume IKE is just
YEF> > used for identity, and not to actually set up an IPsec tunnel for secure
YEF> > communications.
YEF> 
YEF> indeed we have to define IPSec actions. not sure if we need to provide a 
YEF> full IPSP configuration in this section. what are the entries which are 
YEF> lacking in the attached version ?

Well, the IPsec parameters would be set up in the ipiaIpsecActionTable,
ipiaIpsecProposalsTable and ipiaIpsecTransformsTable, along with the necessary
related tables. You would then need a rule to trigger the row in the
ipiaIpsecActionTable. You would probably want a single rule, with a compound
action composed of an IKE sub-action and an IPsec sub-action.


YEF> > 10) There is only one spdRuleDefinition (matching IKE Phase 1
YEF> > traffic). Since an interface that has a group entry will drop any packet
YEF> > that doesn't match any rules, this means that all non IKE Phase 1
YEF> > traffic would be dropped [...]
YEF> 
YEF> done. added a section "common setup" to make it explicit in the draft.
YEF> the example focus on DHCP traffic.

What you have will work, but I suggest using a more generic entry in the group
contents table (e.g. "Accept allowed unprotected traffic"), with a compound
filter and sub-filters for each allowed traffic type. This would allow the
single compound filter to be applied to multiple interfaces, whereas your
current setup in the group contents table would have to be replicated for every
interface. So if there are N interfaces and M allowed traffic types, filtering
in group contents would be (N * M) rows, versus (N + M) rows when using a
compound filter.


YEF> > 12) You may also want to mention that [...] If these objects are not
YEF> > set, the default [is to] accept all packets to the interface. 
YEF> 
YEF> can we consider it's done through the definition of the common setup 
YEF> section (see your comment #10) ?

Yes, that's fine.


Just one other comment on the new section 6 IKE:

13) you define a peer identity filter, but it is not used anywhere. If relying
on the shared secret if not sufficient and you want to use a filter on the
identity, then the filter for spdGroupContentsTable, row 4 should be a compound
filter, with sub-filters of spdIpHeaderFilterTable.1 and
ipiaPeerIdentityFilterTable.1.


Now, on to the PANA-EP-MIB.

I'm assuming that the panaL2FilterTable is intended to be used as a means to
trigger panaNewPacL2Notification messages, and not as a filter type for use
with the IPsec policy MIBs. The use of the table does not appear to be defined
in the draft.

This is not a problem, or even a suggestion. Just food for thought. In general,
the more flexible a filter, the better. This table is filtering on MAC
addresses. For ethernet addresses, the MAC has a prefix that identifies the
manufacturer of the interface. So, if you have a homogeneous network of devices
with ethernet interfaces from one (or a few) vendors, filtering based on the
vendor prefix might be useful. If the panaL2FitlerTable had an additional
column, panaL2FileAddrPrefix, then this could easily be accomplished. The
default value should be 0, so the table would require exact matches by default.

Another flexibility idea for the panaL2FilterTable would be to explicity define
the action to be taken on a match. The default would likely be to send the
panaNewPacL2Notification, but if a particular MAC was determined to be an
attacker, it would be useful to set the action to drop/ignore, so that
resources would not be wasted attempting negotiations.

I would also suggest a MIB level object for setting a threshold for sending the
notifications. If you are getting 10 packets per second from somewhere, you
don't really need to send a trap every time. A simple integer object defining
the number of seconds that packets will be ignored before a new notification is
sent.