Re: IPSP MIBs usage review needed

On Fri, 12 Nov 2004 06:38:44 -0800 Wes wrote:
WH> >>>>> On Tue, 28 Sep 2004 17:41:54 +0200, [email protected]
WH> >said:
WH> Yacine> our document in the PANA WG proposes to re-use the IPSP MIBs
WH> Yacine> in the PANA framework for authorization features. we need
WH> Yacine> people from this group to review the usage example in our I-D
WH> Yacine> (section 6, page 16):
WH> Yacine>
WH> Yacine> http://www.ietf.org/internet-drafts/draft-ietf-pana-snmp-01.txt
WH> 
WH> Hi, and sorry for the delay.  I told the PANA working group that I (or
WH> one of the authors) will read the PANA MIB and review it for you to
WH> check its usage of the IPSP MIBs.

Here are my comments on the usage example. I'll try to get to the rest of it
tomorrow. Let me know if you have questions or need further clarification.

1) You seem to use the notation "xxxTable.N" to indicate the Nth entry in a
table. Unfortunately, this looks like an OID and could be confusing. I
recommend using some other notation, such as "xxxTable, row 1". This is
especially confusing when you use the notation as an example value for an
object that actually takes an OID (eg spdGroupContFilter).

Section 6.1
----------- 
2) The spdRuleDefFilter in the spdRuleDefinitionTable
rows should be set to spdTrueFilterInstance, since the filter in the
spdGroupContents table has already matched.

3) I recommend using spdAcceptAction instead of spdStaticActions.2, for
readability.

Section 6.2
-----------
4) you state that the previous configuration set is still valid, but you reuse
the spdGroupContName "EP-SPD-IN" from spdGroupContentsTable row 1 defined in
6.1 with the same priority and a different filter. I recommend you use examples
that could co-exist, which would mean

  a) defining row 1 of the spdGroupContentsTable in section 6.1 to use a
     lower priority (higher spdGroupContPriority, eg 1000).

  b) defining row 1 (hopefully renamed to row 3) in the spdGroupContentsTable
     in section 6.2 with a higher priority (I'm guessing the IKE rule should
     have the higher priority(lower spdGroupContPriority, eg 1)).

5) in spdGroupContentsTable.1 (hopefully renamed), I recommend using
ipiaIkePhase1Filter instead of ipiaStaticFilters.1, for readability.

6) the spdRuleDefFilter in spdRuleDefinitionTable row 3 should be set to
spdTrueFilterInstance, since the filter in the spdGroupContents table has
already matched. The spdRuleDefAction should refer to ipiaIkeActionTable, not
spdIkeActionTable.

7) You defined an ipiaIkeActionTable row, but not any associated
ipiaIkeActionProposalsTable and ipiaIkeProposalTable rows.

8) pre-shared keys should be stored in the ipiaCredentialTable. The
ipiaCredentialFilterTable is for matching incoming credentials from peers.

9) You define IKE actions, but no IPsec actions, so I assume IKE is just used
for identity, and not to actually set up an IPsec tunnel for secure
communications.

10) There is only one spdRuleDefinition (matching IKE Phase 1
traffic). Since an interface that has a group entry will drop any packet that
doesn't match any rules, this means that all non IKE Phase 1 traffic would be
dropped, even if the Phase 1 negotiation completes. Thus, Phase 2 negotiation
isn't possible, unless further rules are added. This would also mean that SNMP
traffic to/from the PAA would be dropped. A common setup section prior to 6.1
might be useful, to define what traffic is allowed for the interface (eg per
section 2.1, PANA, ARP, IPv6 discover, DHCP, etc).

11) I also couldn't tell who initiates the IKE exchange. Is it always one side
or the other?

12) You may also want to mention that the IPSP-SPD-MIB specifies that if an
interface has no spdEndpointToGroup defined, the spdIncomingPolicyGroupName and
spdOutgoingPolicyGroupName objects are used to apply policy. If these objects
are not set, the default it accept all packets to the interface. It is
generally accepted that "reject unless accepted" is more secure than "accept
unless rejected", so the PAA may want to create a reject policy and set these
objects ASAP.