Subject: Re: IPSP MIBs usage review needed

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Nov 2004 16:53:06 -0500

-----BEGIN PGP SIGNED MESSAGE-----

I had a long talk with Wes Hardaker about the IPSP MIB.

My understanding was that it simply can not progress, because the
requirement that it use the DTMF object model conflicts with MIB doctor
review that suggests that the MIB should be far simpler.

Someone will need to make a decision so that this MIB can progress.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 12 Nov 2004 00:04:22 -0700

We dealt with this for the PIB, and for most issues, reference to the
DMTF OM was sufficient explanation to satisfy the reviewers.

Hilarie

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 12 Nov 2004 06:38:44 -0800

>>>>> On Tue, 28 Sep 2004 17:41:54 +0200, [email-masked] said:

Yacine> our document in the PANA WG proposes to re-use the IPSP MIBs
Yacine> in the PANA framework for authorization features. we need
Yacine> people from this group to review the usage example in our I-D
Yacine> (section 6, page 16):
Yacine>
Yacine> http://www.ietf.org/internet-drafts/draft-ietf-pana-snmp-01.txt

Hi, and sorry for the delay.  I told the PANA working group that I (or
one of the authors) will read the PANA MIB and review it for you to
check its usage of the IPSP MIBs.

-- 
Wes Hardaker
Sparta

---

From: Robert Story <[email-masked]>
Date: Thu, 18 Nov 2004 14:04:26 -0500

On Fri, 12 Nov 2004 06:38:44 -0800 Wes wrote:
WH> >>>>> On Tue, 28 Sep 2004 17:41:54 +0200, [email-masked]
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.

---

From: Robert Story <[email-masked]>
Date: Sun, 28 Nov 2004 12:49:35 -0500

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

---

From: [email-masked]
Date: Tue, 30 Nov 2004 16:37:46 +0100

without the attachements for the mailing lists:

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

[yacine]: yes it does clarify. thx.

> 2 negotiations, and result in a Phase 2 SA being created, upon successful

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

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

> action composed of an IKE sub-action and an IPsec sub-action.

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

> in group contents would be (N * M) rows, versus (N + M) rows when using a

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

> 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

> with the IPsec policy MIBs. The use of the table does not appear to be defined

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

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

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

> the number of seconds that packets will be ignored before a new notification is

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

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