Re: IPSP MIBs usage review needed

without the attachements for the mailing lists:

--------------------------------------------------------------------------------
> On Thu, 25 Nov 2004 10:41:33 +0100 [email protected] 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

[yacine]: yes it does clarify. thx.

> 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.

[yacine]: agree. some of this text has been added to the example section
to facilitate understanding.

> 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).

[yacine]: ok I updated the section accordingly. the right name of the
table is ipsaCredentialTable. shared-secret is also a proposed option
(2) for the the type field of the credentialFilterTable: this could
bring some confusion.

> 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.

[yacine]: ok. added some text on this in the new version.

> 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.

[yacine]: what you suggests is nice. The -03b version takes this into
account.

> 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.

[yacine]: ok. -03b integrates the changes.

> Now, on to the PANA-EP-MIB.

[yacine]: firstly, thanks for your help. I am planning to do another
thread with the PANA-EP-MIB specific issues ASAP, with other reviews we
received recently. anyway let me answer a couple of your comments:

> 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.

[yacine]: indeed the PANA L2 filter is intended to filter the PaC
traffic at the Link-Layer level.

the additional PANA-EP-MIB module has been designed as simple as
possible: by default a L2 EP implements a reject all traffic (except
PANA, DHCP, etc.) and an entry in the panaL2FilterTable corresponds to
an authorized L2 traffic. this should be independent from the IPSP MIBs
which are re-used  only for the IP scenarii.

> 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.

[yacine]: this table is not intending to filter only MAC addresses,
other L2 addressing are supported as well (PhysAddress). it has been
designed as generic as possible.

> 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.

[yacine]: your proposal sounds nice and consistent. there could be an
elegant integration into the IPSP model. depends of the need of the
working group.

> 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.

[yacine]: this issue has been raised already. I'll keep you informed.

-------------------------------------------------------------------------------