Subject: [Pana] Re: IPSP MIBs usage review needed

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

without the attachements for the mailing lists:

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

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

-------------------------------------------------------------------------------
draft-ietf-pana-snmp-03a.txt

draft-ietf-pana-snmp-03b.txt

skipping to change at page 2, line 36

skipping to change at page 2, line 36

4.2.5 Accounting Consideration . . . . . . . . . . . . . . . 10

4.2.5 Accounting Consideration . . . . . . . . . . . . . . . 10

4.2.6 Peer Liveness Test and Rebooted Peer Detection . . . . 10

4.2.6 Peer Liveness Test and Rebooted Peer Detection . . . . 10

5. Applicability of IPSec configuration MIBs . . . . . . . . . . 12

5. Applicability of IPSec configuration MIBs . . . . . . . . . . 12

5.1 General Access Control . . . . . . . . . . . . . . . . . . 12

5.1 General Access Control . . . . . . . . . . . . . . . . . . 12

5.2 Network Layer Secure Access Control (IPSec) . . . . . . . 14

5.2 Network Layer Secure Access Control (IPSec) . . . . . . . 14

5.3 Notification of PaC presence . . . . . . . . . . . . . . . 15

5.3 Notification of PaC presence . . . . . . . . . . . . . . . 15

6. EP Configuration Example . . . . . . . . . . . . . . . . . . . 16

6. EP Configuration Example . . . . . . . . . . . . . . . . . . . 16

6.1 Common setup . . . . . . . . . . . . . . . . . . . . . . . 16

6.1 Common setup . . . . . . . . . . . . . . . . . . . . . . . 16

6.2 General IP-based Access Control . . . . . . . . . . . . . 17

6.2 General IP-based Access Control . . . . . . . . . . . . . 17

6.3 IPSec-based Access Control . . . . . . . . . . . . . . . . 18

6.3 IPSec-based Access Control . . . . . . . . . . . . . . . . 18

7. PANA extension to the IPSec SPD MIB . . . . . . . . . . . . . 21

7. PANA extension to the IPSec SPD MIB . . . . . . . . . . . . . 22

7.1 PANA MIB Overview . . . . . . . . . . . . . . . . . . . . 21

7.1 PANA MIB Overview . . . . . . . . . . . . . . . . . . . . 22

7.2 PANA-specific objects definition . . . . . . . . . . . . . 21

7.2 PANA-specific objects definition . . . . . . . . . . . . . 22

8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31

8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 32

8.1 Security Issue on PaC presence notification . . . . . . . 31

8.1 Security Issue on PaC presence notification . . . . . . . 32

8.2 MIB usage example . . . . . . . . . . . . . . . . . . . . 31

8.2 MIB usage example . . . . . . . . . . . . . . . . . . . . 32

8.3 Link-layer protection support . . . . . . . . . . . . . . 31

8.3 Link-layer protection support . . . . . . . . . . . . . . 32

9. Security Considerations . . . . . . . . . . . . . . . . . . . 32

9. Security Considerations . . . . . . . . . . . . . . . . . . . 33

10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33

10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34

11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34

11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35

11.1 Normative References . . . . . . . . . . . . . . . . . . . . 34

11.1 Normative References . . . . . . . . . . . . . . . . . . . . 35

11.2 Informative References . . . . . . . . . . . . . . . . . . . 36

11.2 Informative References . . . . . . . . . . . . . . . . . . . 37

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37

Intellectual Property and Copyright Statements . . . . . . . . 38

Intellectual Property and Copyright Statements . . . . . . . . 39

1. Terminology and Definitions

1. Terminology and Definitions

PANA: Protocol for Carrying Authentication for Network Access.

PANA: Protocol for Carrying Authentication for Network Access.

PaC (PANA Client):

PaC (PANA Client):

The client side of the protocol that resides in the host device,

The client side of the protocol that resides in the host device,

which is responsible for providing the credentials to prove its

which is responsible for providing the credentials to prove its

identity for network access authorization. A PaC is responsible

identity for network access authorization. A PaC is responsible

skipping to change at page 16, line 31

skipping to change at page 16, line 31

spdEndGroupIdentType = IPv4;

spdEndGroupIdentType = IPv4;

spdEndGroupAddress = EP-ADDR;

spdEndGroupAddress = EP-ADDR;

spdEndGroupName = "EP-SPD-IN";

spdEndGroupName = "EP-SPD-IN";

spdEndpointToGroupTable, row 2:

spdEndpointToGroupTable, row 2:

spdEndGroupDirection = outgoing;

spdEndGroupDirection = outgoing;

spdEndGroupIdentType = IPv4;

spdEndGroupIdentType = IPv4;

spdEndGroupAddress = EP-ADDR;

spdEndGroupAddress = EP-ADDR;

spdEndGroupName = "EP-SPD-OUT";

spdEndGroupName = "EP-SPD-OUT";

Within each of the policy group defined above, we define a rule

Within each of the policy group defined above, we define a sub-group

dedicated to the treatment of traffic that is allowed prior to any

(a compound filter) dedicated to the treatment of traffic that is

configuration, namely PANA, ARP, IPv6 discover, DHCP, etc.

allowed prior to any configuration. The following configuration

illustrates the incoming allowed unprotected traffic:

The following configuration illustrates the case of incoming DHCP

traffic:

spdGroupContentsTable, row 2:

spdGroupContentsTable, row 2:

spdGroupContName = "EP-SPD-IN";

spdGroupContName = "EP-SPD-IN";

spdGroupContPriority = '10';

spdGroupContPriority = '10';

spdGroupContFilter = spdTrueFilterInstance;

spdGroupContComponentType = group;

spdGroupContComponentName = "EP-ALLOWED-UNPROTECTED-IN";

Within this sub-group, we define a rule (a sub-filter) dedicated to

each allowed traffic types (namely PANA, ARP, IPv6 discover, DHCP,

etc). The following configuration illustrates the case of incoming

DHCP traffic:

spdGroupContentsTable, row 3:

spdGroupContName = "EP-ALLOWED-UNPROTECTED-IN";

spdGroupContPriority = '1';

spdGroupContFilter = spdIpHeaderFilterTable.10;

spdGroupContFilter = spdIpHeaderFilterTable.10;

spdGroupContComponentType = rule;

spdGroupContComponentType = rule;

spdGroupContComponentName = "EP-DHCP-ACCEPT-IN";

spdGroupContComponentName = "EP-DHCP-ACCEPT-IN";

We define the corresponding filter in the IP Header filter table,

We define the corresponding filter in the IP Header filter table,

which matches the DHCP packets:

which matches the DHCP packets:

spdIpHeaderFilterTable, row 10:

spdIpHeaderFilterTable, row 10:

spdIpHeadFiltName = "DHCP Filter";

spdIpHeadFiltName = "DHCP Filter";

spdIpHeadFiltType = { sourcePort ON, protocol ON };

spdIpHeadFiltType = { sourcePort ON, protocol ON };

spdIpHeadFiltIPVersion = v4;

spdIpHeadFiltIPVersion = v4;

spdIpHeadFiltDstLowPort = '546' (DHCP);

spdIpHeadFiltDstLowPort = '546' (DHCP);

spdIpHeadFiltDstHighPort = '547' (DHCP);

spdIpHeadFiltDstHighPort = '547' (DHCP);

spdIpHeadProtocol = '17' (UDP);

spdIpHeadProtocol = '17' (UDP);

The "Rule Defininition" table links a rule with a given action in the

The "Rule Defininition" table links a rule with a given action in the

SPD action MIB. E.g. the following entries links the two filters

SPD action MIB. E.g. the following entries links the filter defined

defined above with the "accept" action statically defined in the SPD

above with the "accept" action statically defined in the SPD MIB

MIB (spdStaticActions.3).

(spdStaticActions.3).

spdRuleDefinitionTable, row 1:

spdRuleDefinitionTable, row 1:

spdRuleDefName = "EP-DHCP-ACCEPT-IN";

spdRuleDefName = "EP-DHCP-ACCEPT-IN";

spdRuleDefDescription = "Allow Incoming DHCP packets";

spdRuleDefDescription = "Allow Incoming DHCP packets";

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilterNegated = false (default);

spdRuleDefFilterNegated = false (default);

spdRuleDefAction = spdAcceptAction;

spdRuleDefAction = spdAcceptAction;

6.2 General IP-based Access Control

6.2 General IP-based Access Control

In this section, we need to configure the SPD so that EP accepts IP

In this section, we need to configure the SPD so that EP accepts IP

packets coming from/going to the client 'PaC1'.

packets coming from/going to the client 'PaC1'.

Within each of the policy group defined above ("EP-SPD-OUT" and

Within the incoming policy group defined above ("EP-SPD-IN"), we

"EP-SPD-IN"), we define a rule dedicated to the treatment of packets

define a rule dedicated to the treatment of packets coming from

coming from/going to "PaC1" and the EP we are provisioning.

"PaC1" and the EP we are provisioning.

spdGroupContentsTable, row 2:

spdGroupContentsTable, row 4:

spdGroupContName = "EP-SPD-IN";

spdGroupContName = "EP-SPD-IN";

spdGroupContPriority = '100';

spdGroupContPriority = '100';

spdGroupContFilter = spdIpHeaderFilterTable.1;

spdGroupContFilter = spdIpHeaderFilterTable.1;

spdGroupContComponentType = rule;

spdGroupContComponentType = rule;

spdGroupContComponentName = "EP-PaC1-ACCEPT-IN";

spdGroupContComponentName = "EP-PaC1-ACCEPT-IN";

spdGroupContentsTable, row 3:

We define the filter in the "IP Header filter" table, which matches

spdGroupContName = "EP-SPD-OUT";

IP packets coming from the PaC:

spdGroupContPriority = '100';

spdGroupContFilter = spdIpHeaderFilterTable.2;

spdGroupContComponentType = rule;

spdGroupContComponentName = "EP-PaC1-ACCEPT-OUT";

We define two filters in the "IP Header filter" table: one match IP

packets coming from the PaC, the other match IP packets going to the

PaC.

spdIpHeaderFilterTable, row 1:

spdIpHeaderFilterTable, row 1:

spdIpHeadFiltName = "PaC1-IP@ Filter SOURCE";

spdIpHeadFiltName = "PaC1-IP@ Filter SOURCE";

spdIpHeadFiltType = { sourceAddress ON };

spdIpHeadFiltType = { sourceAddress ON };

spdIpHeadFiltIPVersion = v4;

spdIpHeadFiltIPVersion = v4;

spdIpHeadFiltSrcAddressBegin = 'PaC1-IP@';

spdIpHeadFiltSrcAddressBegin = 'PaC1-IP@';

spdIpHeadFiltSrcAddressEnd = 'PaC1-IP@';

spdIpHeadFiltSrcAddressEnd = 'PaC1-IP@';

spdIpHeaderFilterTable, row 2:

spdIpHeaderFilterTable, row 2:

spdIpHeadFiltName = "PaC1-IP@ Filter DEST";

spdIpHeadFiltName = "PaC1-IP@ Filter DEST";

spdIpHeadFiltType = { destAddress ON };

spdIpHeadFiltType = { destAddress ON };

spdIpHeadFiltIPVersion = v4;

spdIpHeadFiltIPVersion = v4;

spdIpHeadFiltSrcAddressBegin = 'PaC1-IP@';

spdIpHeadFiltSrcAddressBegin = 'PaC1-IP@';

spdIpHeadFiltSrcAddressEnd = 'PaC1-IP@';

spdIpHeadFiltSrcAddressEnd = 'PaC1-IP@';

The following entries links the two filters defined above with the

The following entries links the two filters defined above with the

"accept" action statically defined in the SPD MIB

"accept" action.

(spdStaticActions.3).

spdRuleDefinitionTable, row 1:

spdRuleDefinitionTable, row 2:

spdRuleDefName = "EP-PaC1-ACCEPT-IN";

spdRuleDefName = "EP-PaC1-ACCEPT-IN";

spdRuleDefDescription = "Allow Incoming IP packets from PaC1";

spdRuleDefDescription = "Allow Incoming IP packets from PaC1";

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilterNegated = false (default);

spdRuleDefFilterNegated = false (default);

spdRuleDefAction = spdAcceptAction;

spdRuleDefAction = spdAcceptAction;

spdRuleDefinitionTable, row 2:

spdRuleDefinitionTable, row 3:

spdRuleDefName = "EP-PaC1-ACCEPT-OUT";

spdRuleDefName = "EP-PaC1-ACCEPT-OUT";

spdRuleDefDescription = "Allow Outgoing IP packets to PaC1";

spdRuleDefDescription = "Allow Outgoing IP packets to PaC1";

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilterNegated = false (default);

spdRuleDefFilterNegated = false (default);

spdRuleDefAction = spdAcceptAction;

spdRuleDefAction = spdAcceptAction;

This results in a policy such that any packet coming from/going to

The same thing must be done for the outgoing direction and this

the PaC is now allowed to go through the EP (via EP-ADDR endpoint).

results in a policy such that any packet coming from/going to the PaC

is allowed to go through the EP (via EP-ADDR endpoint).

6.3 IPSec-based Access Control

6.3 IPSec-based Access Control

In this section we consider the case when IPSec is used to control

In this section we consider the case when IPSec is used to control

access at the IP level. In order to avoid many redundancies, the

access at the IP level. In order to avoid many redundancies, the

previous configuration set is still valid. See below a usage example

previous configuration set is still valid. See below a usage example

of IKEACTION-MIB.

of IKEACTION-MIB.

-- IKE Phase 1 configuration (agressive mode):

-- IKE Phase 1 configuration (agressive mode):

We define a rule in policy group "EP-SPD-IN" of the SPD MIB, using

We define a first-level filter in policy group "EP-SPD-IN" of the SPD

the "Group contents" table. This rule is dedicated to all IKE phase

MIB, using the "Group contents" table. This filter isolates IKE

1 traffic coming to the EP on this interface:

phase 1 traffic coming to the EP on this interface:

spdGroupContentsTable, row 6:

spdGroupContentsTable, row 3:

spdGroupContName = "EP-SPD-IN";

spdGroupContName = "EP-SPD-IN";

spdGroupContPriority = '1';

spdGroupContPriority = '1';

spdGroupContFilter = ipiaIkePhase1Filter;

spdGroupContFilter = ipiaIkePhase1Filter;

spdGroupContComponentType = sub-group;

spdGroupContComponentType = group;

spdGroupContComponentName = "EP-IKE-Phase1-IN";

spdGroupContComponentName = "EP-IKE1-IN";

And within this IKE-specific policy sub-group we now specify the rule

Within this IKE-specific policy sub-group, we specify a second-level

to apply for the IKE traffic coming from PaC1.

filter to apply for for the traffic coming from PaC1.

spdGroupContentsTable, row 4:

spdGroupContentsTable, row 7:

spdGroupContName = "EP-IKE-Phase1-IN";

spdGroupContName = "EP-IKE-Phase1-IN";

spdGroupContPriority = '1';

spdGroupContPriority = '1';

spdGroupContFilter = spdIpHeaderFilterTable.1;

spdGroupContFilter = spdIpHeaderFilterTable.1;

spdGroupContComponentType = rule;

spdGroupContComponentType = group;

spdGroupContComponentName = "PaC1-IKE-RULE";

spdGroupContComponentName = "EP-IKE1-PaC1-IN";

The spdIpHeaderFilterTable.1 entry has been defined in the previous

The spdIpHeaderFilterTable.1 entry has been defined in the previous

seciton.

section. Within the lattest sub-group we finally specify the rule to

apply for the IKE traffic coming from PaC1 and matching the right

identity (id_key_id).

spdGroupContentsTable, row 8:

spdGroupContName = "EP-IKE1-PaC1-IN";

spdGroupContPriority = '1';

spdGroupContFilter = ipiaPeerIdentityFilterTable.1;

spdGroupContComponentType = rule;

spdGroupContComponentName = "PaC1-IKE1-RULE";

The "Peer Identity Filter" table specifically informs the EP on the

value of the idKeyId to use in IKE messages:

ipiaPeerIdentityFilterTable, row 1:

ipiaPeerIdFiltName = "PaC1-IKE1-ID-FILTER";

ipiaPeerIdFiltIdentityType = id_Key_Id;

ipiaPeerIdFiltIdentityValue = 'PANA-Session-Id|PANA-Key-Id';

The "Rule Defininition" table links a rule with a given action in the

The "Rule Defininition" table links a rule with a given action in the

IKE action MIB. This action will be triggereed upon reception at the

IKE action MIB. This action will be triggered upon reception at the

EP of an IKE packet coming from PaC1.

EP of an IKE phase 1 packet coming from PaC1 and matching the right

id_key_id.

spdRuleDefinitionTable, row 3:

spdRuleDefinitionTable, row 4:

spdRuleDefName = "PaC1-IKE-RULE";

spdRuleDefName = "PaC1-IKE-RULE";

spdRuleDefDescription = "IPSec Access Control for PaC1";

spdRuleDefDescription = "IPSec Access Control for PaC1";

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilterNegated = false (default);

spdRuleDefFilterNegated = false (default);

spdRuleDefAction = ipiaIkeActionTable.1;

spdRuleDefAction = ipiaIkeActionTable.1;

The spdRuleDefAction attribute in the entry above points to a row in

The "IKE action" entry below specifies the main parameters for the

the ipiaIkeActionTable, defined below:

IKE exchanges.

ipiaIkeActionTable, row 1:

ipiaIkeActionTable, row 1:

ipiaIkeActName = "PaC1-IKE";

ipiaIkeActName = "PaC1-IKE";

ipiaIkeActParametersName = "SA-PaC1";

ipiaIkeActParametersName = "SA1-PaC1";

ipiaIkeActThresholdDerivedKeys = '100' (default);

ipiaIkeActThresholdDerivedKeys = '100' (default);

ipiaIkeActExchangeMode = aggressive;

ipiaIkeActExchangeMode = aggressive;

ipiaIkeActAgressiveModeGroupId = 'xxx' (Diffie-Hellman values);

ipiaIkeActAgressiveModeGroupId = 'xxx' (Diffie-Hellman values);

ipiaIkeActIdentityType = id_Key_Id;

ipiaIkeActIdentityType = id_Key_Id;

ipiaIkeActIdentityContext = "PANA";

ipiaIkeActIdentityContext = "PANA";

ipiaIkeActPeerName = "PaC1";

ipiaIkeActPeerName = "PaC1";

The following entries give the necessary information for the IKE

The following entry links together the "PaC1" identity with the

Phase 2 exchanges:

corresponding credentials table entry:

ipiaIkeIdentityTable, row 1:

spdEndGroupIdentType = IPv4;

spdEndGroupAddress = 'EP-ADDR';

ipiaIkeActIdentityType = id_Key_Id;

ipiaIkeActIdentityContext = 'PANA';

ipiaIkeIdCredentialName = "PaC1-PSK";

Finally, the pre-shared key derivated at the PAA is set in the IPSA

Credentials table:

ipsaCredentialTable, row 1:

ipsaCredName = "PaC1-PSK";

ipsaCredType = sharedSecret;

ipsaCredCredential = 'PSK-derived-at-the-PAA';

ipsaCredSize = 'xxx';

ipsaMgnName = "xxx";

ipsaRemoteID = 'PaC1';

The Ike Action entry (above) is indexed by a name (ipiaIkaActName

attribute), which is used as the primary index into the

ipiaIkeActionProposalsTable. The secondary index is a priority,

which allows ordering of the proposals that will be sent to the peer

(or accepted from the peer).

ipiaIkeActionProposalsTable, row 1:

ipiaIkeActionProposalsTable, row 1:

ipiaIkeActPropName = "PaC1-IKE";

ipiaIkeActPropName = "PaC1-IKE-PROP1";

ipiaIkeActPropPriority = '1';

ipiaIkeActPropPriority = '1';

The ipiaIkeActPropName points to a row in the ipiaIkeProposalsTable,

which contains the actual IKE parameters for the Phase 1 exchanges:

ipiaIkeProposalsTable, row 1:

ipiaIkeProposalsTable, row 1:

ipiaIkeActPropName = "PaC1-IKE";

ipiaIkeActPropName = "PaC1-IKE-PROP1";

ipiaIkePropLifetimeDerivedKeys = xxx;

ipiaIkePropLifetimeDerivedKeys = xxx;

ipiaIkePropCipherAlgorithm = 3DES;

ipiaIkePropCipherAlgorithm = 3DES;

ipiaIkePropCipherKeyLength = xxx;

ipiaIkePropCipherKeyLength = xxx;

ipiaIkePropHashAlgorithm = HMAC-SHA1;

ipiaIkePropHashAlgorithm = HMAC-SHA1;

ipiaIkePropPrfAlgorithm = xxx;

ipiaIkePropPrfAlgorithm = xxx;

ipiaIkePropVendorId = xxx;

ipiaIkePropVendorId = xxx;

ipiaIkePropDhGroup = 2;

ipiaIkePropDhGroup = 2;

ipiaIkePropAuthenticationMethod = xxx;

ipiaIkePropAuthenticationMethod = xxx;

ipiaIkePropMaxLifetimeSecs = xxx;

ipiaIkePropMaxLifetimeSecs = xxx;

ipiaIkePropMaxLifetimeKB = xxx;

ipiaIkePropMaxLifetimeKB = xxx;

ipiaSaNegotiationParametersTable, row 1:

There is a similar hierarchy for the proposals, which are used for

ipiaSaNegParamName = "SA-PaC1";

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

ipiaSaNegParamMinLifetimeSecs = xxx;

successful negotiations. The parameters would be set up in the

ipiaSaNegParamMinLifetimeKB = xxx;

ipiaIpsecActionTable, ipiaIpsecProposalsTable and

ipiaSaNegParamRefreshThreshSecs = xxx;

ipiaIpsecTransformsTable, along with the necessary related tables.

ipiaSaNegParamRefreshThresholdKB = xxx;

One would then need a rule to trigger the row in the

ipiaSaNegParamIdleDurationSecs = xxx;

ipiaIpsecActionTable. See for further details on the IPSP MIBs

usage.

The "Peer Identity" table specifically informs the EP on the value of

the idKeyId to use in IKE messages with PaC1:

ipiaPeerIdentityFilterTable, row 1:

ipiaPeerIdFiltName = "PaC1";

ipiaPeerIdFiltIdentityType = id_Key_Id;

ipiaPeerIdFiltIdentityValue = 'PANA-Session-Id|PANA-Key-Id';

The pre-shared key derivated at the PAA is set in the Credentials

table:

ipiaCredentialFilterTable, row 1:

ipiaCredFiltName = "PaC1-PSK";

ipiaCredFiltCredentialType = sharedSecret;

ipiaCredFiltMatchFieldName = none;

ipiaCredFiltMatchFieldValue = 'PSK-derived-at-the-PAA';

Finally, the following entry links together the "PaC1" identity with

the corresponding "PaC1-PSK" Credentials table entry:

ipiaIkeIdentityTable, row 1:

spdEndGroupIdentType = IPv4;

spdEndGroupAddress = 'EP-ADDR';

ipiaIkeActIdentityType = id_Key_Id;

ipiaIkeActIdentityContext = 'PANA';

ipiaIkeIdCredentialName = "PaC1-PSK";

7. PANA extension to the IPSec SPD MIB

7. PANA extension to the IPSec SPD MIB

Many existing IPSec MIB objects defined in the IPSec Configuration

Many existing IPSec MIB objects defined in the IPSec Configuration

MIB modules can be efficiently re-used for the PANA-specific needs.

MIB modules can be efficiently re-used for the PANA-specific needs.

This is detailed in Section 5.

This is detailed in Section 5.

The following sections define additional PANA-specific objects that

The following sections define additional PANA-specific objects that

extend the IPSec MIB module in order to entirely satisfy the PAA-EP

extend the IPSec MIB module in order to entirely satisfy the PAA-EP

interface requirements.

interface requirements.

skipping to change at page 33, line 7

skipping to change at page 34, line 7

Further, deployment of SNMP versions prior to SNMPv3 is NOT

Further, deployment of SNMP versions prior to SNMPv3 is NOT

RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to

RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to

enable cryptographic security. It is then a customer/operator

enable cryptographic security. It is then a customer/operator

responsibility to ensure that the SNMP entity giving access to an

responsibility to ensure that the SNMP entity giving access to an

instance of this MIB module is properly configured to give access to

instance of this MIB module is properly configured to give access to

the objects only to those principals (users) that have legitimate

the objects only to those principals (users) that have legitimate

rights to indeed GET or SET (change/create/delete) them.

rights to indeed GET or SET (change/create/delete) them.

10. Acknowledgements

10. Acknowledgements

This document originaly leverages on similar works done in the MIDCOM

Many thanks to Robert Story, who provided very helpful

working group. Thanks to the authors of those IDs.

recommendations on the IPSP MIBs usage.

The author would like to thank Thomas Moore and Olivier Marce for

This document originaly leverages on similar works done in the MIDCOM

their grateful help during the edition of this document.

working group. Thanks to the authors of those IDs. Thanks to Thomas

Moore and Olivier Marce for their grateful help during the edition of

this document.

11. References

11. References

11.1 Normative References

11.1 Normative References

[I-D.ietf-pana-pana]

[I-D.ietf-pana-pana]

Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.

Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.

Yegin, "Protocol for Carrying Authentication for Network

Yegin, "Protocol for Carrying Authentication for Network

Access (PANA)", draft-ietf-pana-pana-06 (work in

Access (PANA)", draft-ietf-pana-pana-06 (work in

progress), October 2004.

progress), October 2004.

End of changes.

This html diff was produced by rfcdiff 1.14, available from http://www.levkowetz.com/ietf/tools/rfcdiff/

PANA Working Group                                         Y. El Mghazli
Internet-Draft                                                   Alcatel
Expires: June 1, 2005                                            Y. Ohba
                                                                 Toshiba
                                                            J. Bournelle
                                                                 GET/INT
                                                           December 2004

                    SNMP usage for PAA-EP interface
                        draft-ietf-pana-snmp-03

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 1, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   The PANA Authentication Agent (PAA) does not necessarily act as an
   Enforcement Point (EP) to prevent unauthorized access or usage of the
   network.  When a PANA Client successfully authenticates itself to the
   PAA, EP(s) (e.g., access routers) will need to be suitably notified.

El Mghazli, et al.        Expires June 1, 2005                  [Page 1]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   The PANA working group mandates the use of Simple Network Management
   Protocol Version 3 (SNMPv3) to deliver the authorization information
   to one or more EPs when the PAA is separated from EPs.

   The present document provides the necessary information and
   extensions needed to use SNMPv3 as the PAA-EP protocol.

Table of Contents

   1.  Terminology and Definitions  . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   PAA/EP separation context  . . . . . . . . . . . . . . . .  4
     2.2   Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  The Internet-Standard Management Framework . . . . . . . . . .  6
   4.  SNMP Applicability with the PANA framework . . . . . . . . . .  7
     4.1   SNMPv3 General applicability . . . . . . . . . . . . . . .  7
     4.2   Compliancy of SNMP against the PANA requirements . . . . .  8
       4.2.1   Authorization Consideration  . . . . . . . . . . . . .  8
       4.2.2   PAA-EP relation  . . . . . . . . . . . . . . . . . . .  9
       4.2.3   Secure Communication . . . . . . . . . . . . . . . . .  9
       4.2.4   Notification of PaC presence . . . . . . . . . . . . .  9
       4.2.5   Accounting Consideration . . . . . . . . . . . . . . . 10
       4.2.6   Peer Liveness Test and Rebooted Peer Detection . . . . 10
   5.  Applicability of IPSec configuration MIBs  . . . . . . . . . . 12
     5.1   General Access Control . . . . . . . . . . . . . . . . . . 12
     5.2   Network Layer Secure Access Control (IPSec)  . . . . . . . 14
     5.3   Notification of PaC presence . . . . . . . . . . . . . . . 15
   6.  EP Configuration Example . . . . . . . . . . . . . . . . . . . 16
     6.1   Common setup . . . . . . . . . . . . . . . . . . . . . . . 16
     6.2   General IP-based Access Control  . . . . . . . . . . . . . 17
     6.3   IPSec-based Access Control . . . . . . . . . . . . . . . . 18
   7.  PANA extension to the IPSec SPD MIB  . . . . . . . . . . . . . 22
     7.1   PANA MIB Overview  . . . . . . . . . . . . . . . . . . . . 22
     7.2   PANA-specific objects definition . . . . . . . . . . . . . 22
   8.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 32
     8.1   Security Issue on PaC presence notification  . . . . . . . 32
     8.2   MIB usage example  . . . . . . . . . . . . . . . . . . . . 32
     8.3   Link-layer protection support  . . . . . . . . . . . . . . 32
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 35
   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 35
   11.2  Informative References . . . . . . . . . . . . . . . . . . . 37
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37
       Intellectual Property and Copyright Statements . . . . . . . . 39

El Mghazli, et al.        Expires June 1, 2005                  [Page 2]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

1.  Terminology and Definitions

   PANA: Protocol for Carrying Authentication for Network Access.

   PaC (PANA Client):

      The client side of the protocol that resides in the host device,
      which is responsible for providing the credentials to prove its
      identity for network access authorization.  A PaC is responsible
      for requesting network access and engaging in authentication
      process using the PANA protocol.

   DI (Device Identifier):

      The identifier used by the network as a handle to control and
      police the network access of a client.  Depending on the access
      technology, this identifier might contain any of IP address,
      link-layer address, switch port number, etc.  of a connected
      device.

   PAA (PANA Authentication Agent):

      The access network (server) side entity of the PANA protocol.  A
      PAA is in charge of interfacing with the PaCs for authenticating
      and authorizing them for the network access service.  To this end,
      the PAA verifies the credentials provided by a PANA client and
      grants network access service to the device associated with the
      client and identified by a DI.
      The PAA is also responsible for updating the access control state
      (i.e., filters) depending on the creation and deletion of the
      authorization state.  The PAA communicates the updated state to
      the enforcement points in the network.  When the PAA and the EP
      are separated, a protocol is required to carry the authorized
      client attributes from the PAA to the EP.  SNMP is mandated for
      this task.

   EP (Enforcement Point):

      A node on the access network where per-packet enforcement policies
      (i.e., filters) are applied on the inbound and outbound traffic of
      client devices.  The EP uses non-cryptographic or cryptographic
      filters to selectively allow and discard data packets.  These
      filters may be applied at the link-layer or the IP-layer.  An EP
      learns the attributes of the authorized clients (DI and
      (optionally) cryptographic keys) from the PAA.

El Mghazli, et al.        Expires June 1, 2005                  [Page 3]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

2.  Introduction

2.1  PAA/EP separation context

   PANA enables access control by identifying legitimate clients and
   generating filtering information for access control mechanisms.
   [I-D.ietf-pana-framework] defines a general AAA and access control
   framework.  The PANA protocol itself provides client authentication
   and authorization functionality for securing network access.  The
   other component of a complete solution is the access control which
   ensures that only authenticated and authorized clients can gain
   access to the network.

   Access control can be achieved by placing EPs (Enforcement Points) in
   the network for policing the traffic flow.  EPs should prevent data
   traffic from and to any unauthorized client unless it's either PANA
   or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor
   discovery, DHCP, etc.).

   Figure 1 below illustrates the functional entities and the interfaces
   (protocols, APIs) among them.

                                              RADIUS/
                                              Diameter/
        +-----+       PANA        +-----+     LDAP/ API    +-----+
        | PaC |<----------------->| PAA |<---------------->| AS  |
        +-----+                   +-----+                  +-----+
           ^                         ^
           |                         |
           |         +-----+         |
      IKE/ +-------->| EP  |<--------+ SNMP/ API
   4-way handshake   +-----+

                    Figure 1: PANA Functional Model

   Some of the entities may be co-located depending on the deployment
   scenario.

   The EP on the access network allows general data traffic from any
   authorized PaC, whereas it allows only limited type of traffic (e.g.,
   PANA, DHCP, router discovery) for the unauthorized PaCs.  This
   ensures that the newly attached clients have the minimum access
   service to engage in PANA and get authorized for the unlimited
   service.

   If the PaC is authorized to gain the access to the network, the PAA
   also sends the PaC-specific attributes (e.g., IP address,
   cryptographic keys, etc.) to the EP by using SNMP.  The EP uses this

El Mghazli, et al.        Expires June 1, 2005                  [Page 4]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   information to enforce policy rules allowing data traffic from and to
   the PaC to pass through.

   In case a cryptographic access control needs to be enabled after the
   PANA authentication, a secure association protocol runs between the
   PaC and the EP.  The PaC should already have the input parameters to
   this process as a result of the successful PANA exchange.  Similarly,
   the EP should have obtained them from the PAA via SNMP.  Secure
   association exchange produces the required security associations
   between the PaC and the EP to enable per-packet protection.

   Finally data traffic can start flowing from and to the newly
   authorized PaC.

2.2  Scope

   Section 3 gives references for the SNMP framework.

   Section 4 provides a general statement with regards to the
   applicability of SNMP as the PAA-EP protocol.

   IPSec MIB modules were found to have general applicability and
   varying levels of re-usability for PANA EP configuration using SNMP.
   Section 5 details the applicability of this MIB set to the EP
   configuration.

   Section 6 provides usage examples of these MIB modules in the context
   of PANA.

   Section 7 defines some additional PANA-specific objects that extend
   the IPSec SPD-MIB module [I-D.ietf-ipsp-spd-mib] in order to entirely
   satisfy the PAA-EP interface requirements.

   Finally, Section 9 addresses the security considerations.

El Mghazli, et al.        Expires June 1, 2005                  [Page 5]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

3.  The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58
   [RFC2578], STD 58 [RFC2579] and STD 58 [RFC2580].

El Mghazli, et al.        Expires June 1, 2005                  [Page 6]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

4.  SNMP Applicability with the PANA framework

   This section provides a general statement with regards to the
   applicability of SNMP as the PAA-EP protocol.  This analysis of SNMP
   is specific to SNMPv3, which provides the security required for PANA
   usage.  SNMPv1 and SNMPv2c would be inappropriate for PANA since they
   have been declared Historic, and because their messages have only
   trivial security.

4.1  SNMPv3 General applicability

   The primary advantages of SNMPv3 are that it is a mature, well
   understood protocol, currently deployed in various scenarios, with
   mature toolsets available for SNMP managers and agents.

   Application intelligence is captured in MIB modules, rather than in
   the messaging protocol.  MIB modules define a data model of the
   information that can be collected and configured for a managed
   functionality.  The SNMP messaging protocol transports the data in a
   standardized format without needing to understand the semantics of
   the data being transferred.  The endpoints of the communication
   understand the semantics of the data.

   Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly
   due to variations in configuration requirements across vendors, few
   MIB modules have been developed that enable standardized
   configuration of managed devices across vendors.  Since monitoring
   can be done using only a least-common-denominator subset of
   information across vendors, many MIB modules have been developed to
   provide standardized monitoring of managed devices.  As a result,
   SNMP has been used primarily for monitoring rather than for
   configuring network nodes.

   SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c
   versions.  Specifically, SNMPv3 shares the separation of data
   modeling (MIBs) from the protocol to transfer data, so all existing
   MIBs can be used with SNMPv3.  SNMPv3 also uses the SMIv2 standard,
   and it shares operations and transport with SNMPv2c.  The major
   difference between SNMPv3 and earlier versions is the addition of
   strong message security and controlled access to data.

   SNMPv3 uses the architecture detailed in [RFC3411], where all SNMP
   entities are capable of performing certain functions, such as the
   generation of requests, response to requests, the generation of
   asynchronous notifications, the receipt of notifications, and the
   proxy-forwarding of SNMP messages.  SNMP is used to read and
   manipulate virtual databases of managed-application-specific
   operational parameters and statistics, which are defined in MIB

El Mghazli, et al.        Expires June 1, 2005                  [Page 7]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   modules.

4.2  Compliancy of SNMP against the PANA requirements

   The following sections detail how the PAA-EP protocol requirements
   are fully supported by SNMP:

4.2.1  Authorization Consideration

   This section discusses PAA-EP communication in terms of authorization
   aspects.

   Binary Authorization:

      Filtering rules to be installed on EP generally include a device
      identifier of PaC, and also a cryptographic keying material (e.g.,
      IKE [RFC2409] pre-shared key ) when cryptographic data traffic
      protection is needed.  Each keying material is uniquely identified
      with a keying material name (e.g., ID_KEY_ID in IKE) and has a
      lifetime for key management, accounting, access control and
      security reasons in general.

      PANA management can be modeled in a way that is consistent with
      existing standard MIB modules, this is detailed in Section 5.
      Additional PANA-specific objects may be needed and are defined in
      Section 7.

   Profile-based authorization:

      In addition to the device identifier and keying material, the PAA
      may provide the EP with additional authorization information.  For
      instance, a user may be authorized to access the network within a
      given class of service or for a maximum amount of units.  The type
      of units can be time (e.g., authorization lifetime), volume (e.g.,
      the number of incoming and/or outgoing packets and/or bytes),
      service specific or money depending on the type of service event
      [I-D.ietf-aaa-diameter-cc].

      There are two possible models to support this type of
      authorization:

      *  In the polling model, the PAA (most probably) periodically
         sends queries to its EP(s) on the current amount of units used
         by each PaC.

      *  In the notification model, the PAA sends the maximum amount
         units to EP(s) when a PaC is successfully authenticated and
         authorized, and waits notification events from EP(s).  The

El Mghazli, et al.        Expires June 1, 2005                  [Page 8]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

         notification events are sent by EP(s) when a PaC has spent the
         maximum amount of units.  With the use of SNMPv3 as the PAA-EP
         protocol, the polling and notification models are supported by
         SNMP get and notification operations, respectively.

      This type of authorization might also require that the
      communicating pair of PAA and EP to detect a dead or rebooted peer
      in order to avoid possible inaccurate accounting.  This aspect is
      discussed in Section 4.2.6.

      In any case, even if it is very likely to occur between the PAA
      and EP, this kind of profile-based authorization is beyond the
      scope of the PANA working group.  Hence, the specification of the
      MIB modules (existing or not) necessary to provide such policy
      information is outside the scope of the present document, which
      deals only with the so-called binary authorization.

4.2.2  PAA-EP relation

   A number of deployment options are envisaged within the PANA
   framework.  See [I-D.ietf-pana-framework] for further details.

   The SNMP framework [RFC3410] supports one-to-many, many-to-one, and
   many-to-many relationships between the SNMP managers (PAAs) and
   agents (EPs).

4.2.3  Secure Communication

   SNMPv3 includes the User-based Security Model (USM, [RFC3414]), which
   provides authentication, confidentiality, and integrity.

   Additionally, USM has specific built-in mechanisms for preventing
   replay attacks including unique protocol engine IDs, timers and
   counters per engine and time windows for the validity of messages.

   See [RFC3410] for the security features provided by the SNMPv3
   framework.

4.2.4  Notification of PaC presence

   The PaC may also choose to start sending packets before getting
   authenticated.  In that case, the network should detect this and the
   PAA must send an unsolicited PANA-Start-Request message to the PaC.
   The EP is the node that can detect such activity.  In case they are
   separate, there needs to be an explicit message to prompt the PAA.

   Such a presence notification is done by using the SNMP notification
   operation.  See Section 5.3 for details on how new and existing SNMP

El Mghazli, et al.        Expires June 1, 2005                  [Page 9]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   objects provide this feature.

4.2.5  Accounting Consideration

   Since authentication and authorization are closely related to
   accounting in many cases, accounting aspects need to be considered in
   the PAA-EP protocol.  There are logically two models with regard to
   where the accounting client is located.

   o  In the first model, the accounting client is co-located with PAA.
      The PAA device acts as an accounting client of a AAA protocol.
      The PAA collects accounting information from the EP(s) it
      controls, and sends the gathered data to the accounting server by
      using the AAA protocol.  In the case where accounting is performed
      in usage basis, i.e., the number of transmitted/received
      octets/packets, the PAA-EP protocol also needs to carry these
      usage data.

   o  In the second model, the accounting client is co-located with the
      EP.  In this model, the EP device acts as an accounting client of
      a AAA protocol.  The EP obtains the authentication/authorization
      session identifier for each PaC from the PAA, where the
      authentication/authorization session identifier is assigned by a
      AAA protocol running on the PAA, and sends the accounting
      information directly to the accounting server by using the AAA
      protocol, without sending the accounting information to the PAA.

   The authentication/authorization session identifier of a AAA protocol
   is used by the accounting server to associate accounting information
   with a particular authentication/authorization session to calculate
   bills.  The authentication/authorization session identifier may or
   may not be the same as the PANA session identifier.

   Both models might need for the communicating pair of the PAA and the
   EP to detect a dead or rebooted peer to avoid possible inaccurate
   accounting.  This aspect is discussed in Section 4.2.6.

4.2.6  Peer Liveness Test and Rebooted Peer Detection

   PAA-EP protocol implementations need to be stateful, when considering
   the authorization and accounting aspects as described in the previous
   sections.  The stateful nature provides the functionality to detect a
   dead or rebooted peer in a timely fashion.  On the other hand, this
   does not mean that the PAA-EP protocol itself needs to be stateful.
   For example, an SNMP entity (i.e., an SNMP engine plus SNMP
   applications) can generate SNMP queries on a particular MIB at an
   interval short enough to perform peer liveness test and rebooted peer
   detection.

El Mghazli, et al.        Expires June 1, 2005                 [Page 10]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   Also, the peer liveness test and rebooted peer detection need to be
   performed securely.

   When SNMPv3 is used as the PAA-EP protocol, the SNMP management
   framework supports snmpEngineBoots MIB [RFC3411].  By periodically
   sending SNMP query to the peer to check the current value of this MIB
   with the use of SNMP Security Subsystem, it is possible for an SNMP
   entity to securely perform peer liveness test and rebooted peer
   detection between PAA and EP.

   When a PAA finds a dead or rebooted EP, the PAA should immediately
   terminate PANA sessions for PaCs that are authorized for access
   through the EP.

El Mghazli, et al.        Expires June 1, 2005                 [Page 11]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

5.  Applicability of IPSec configuration MIBs

   This section details the applicability of existing IPSec
   configuration MIB modules to the EP configuration.  These were found
   to have general applicability and a fair level of re-usability for
   the PANA EP configuration:

   IPSec Security Policy Database (SPD) MIB:
      [I-D.ietf-ipsp-spd-mib] defines a MIB module for configuration of
      an IPSec Security Policy Database (SPD).  No IPSec or IKE specific
      actions are defined within this document.

   IPSec IKE Action MIB:
      [I-D.ietf-ipsp-ikeaction-mib] defines a MIB module for
      configuration of an IKE action within the IPSec SPD.

   The IPSec Configuration MIBs set does not define MIB modules for
   monitoring the state of an IPSec device.  Neither it does define MIB
   modules for configuring other policy related actions.  The purpose of
   these MIBs is to allow administrators to be able to configure policy
   with respect to the IPSec [RFC2401]/IKE [RFC2409] protocols.

5.1  General Access Control

   The EP enforces binary authorization by filtering data traffic on the
   basis of the Device Identifier (DI) of the PaC.  The PAA must
   provision its EPs with DI-based filters in order to control and
   police the network access of a PaC.  According to the definition of
   the Device Identifier in [I-D.ietf-pana-requirements], such filters -
   depending on the access technology - might be either a IPv4/6 address
   or a link-layer address of a connected device.  Do note also that a
   keying material might be provisioned.  The particular case where
   access control is performed using IPSec is specified in
   [I-D.ietf-pana-ipsec].  The configuration aspects are detailed in
   Section 5.2.

   The IPSec SPD MIB module (SPD-MIB) is designed to configure an IPSec
   security policy database in a policy and rule oriented fashion.  This
   module is divided into 3 portions (Rules, Filters, Actions).
   Specifically, SPD-MIB provides a generic mechanism for performing
   packet processing based on a rule set.

   The policy-based packet filtering and the corresponding execution of
   actions is of a more general nature than for IPSec configuration
   only, such as for configuration of a firewall.  Rules within the
   IPSec SPD-MIB are generic and simply bind a filter to an action.
   Filters provided within the SPD-MIB itself are numerous and fairly
   complete for most common packet filtering usage but externally

El Mghazli, et al.        Expires June 1, 2005                 [Page 12]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   defined filters are supported.

   Below are basic DI-based filters and static actions that are used --
   together with the other SPD tables -- to enforce binary packet
   authorization at the EP:

   -- Ipv4/v6 address-based filter:

      For Ipv4/v6 address-based filters provisioning, the IPSec SPD-MIB
      provides means to filter the traffic based on the IP header
      information.  SPD-MIB "spdIpHeaderFilter" table provides such
      facilities: one can define the various tests that are used when
      evaluating a given IP packet.  The various tests definable in this
      table are as follows:

      *  Source Address Match
      *  Destination Address Match
      *  Source Port Range Match
      *  Destination Port Range Match
      *  Protocol Match
      *  IPv6 Flow Label Match (Ipv6 only)

      The results of each test are ANDed together to produce the result
      of the entire filter.

   -- L2 address-based filter:

      [I-D.ietf-pana-pana] says the Device-Id AVP (code 1025) is of
      Address Type [RFC3588].  The content for link-layer addresses is
      expected to be specified in specific documents that describe how
      IP operates over different link-layers.  For instance, [RFC2464].
      To this end, additional filters are designed in the present
      document.  Section 7 defines a link-layer filter table, which test
      the L2 address (e.g.  MAC address, port, DSL line) of a given
      packet.
      Do note that the definition of this table does not assume the
      usage of any particular Link layer.

   -- Static Actions:

      The actions encapsulated within the SPD-MIB module are basic
      drop/accept actions.  These are sufficient to perform EP general
      binary authorization enforcement at the EP.
      When profile-based authorization information is provided to the
      EP, more advanced actions like classifiers, meters and schedulers
      might be configured by the PAA.  This is out of the scope of the
      present document.

El Mghazli, et al.        Expires June 1, 2005                 [Page 13]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

5.2  Network Layer Secure Access Control (IPSec)

   The PANA protocol authenticates the client and also establishes a
   PANA security association between the PANA client and PANA
   authentication agent at the end of successful authentication.  The
   PAA indicates the results of the authentication using the
   PANA-Bind-Request (PBR) message wherein it can indicate the access
   control method enforced by the access network and the IP address of
   the corresponding EP.

   When IPSec is used to perform access control, the PANA protocol
   [I-D.ietf-pana-pana] does not discuss any details of IPSec [RFC2401]
   SA establishment.  Indeed, [I-D.ietf-pana-ipsec] discusses the
   details for establishing an IPSec security association between the
   PaC and the EP.  When the IPSec SA is successfully established, it
   can be used to enforce access control and specifically used to
   prevent the service theft mentioned in [I-D.ietf-pana-threats-eval].

   In this particular context, one assumes that the following have
   already happened before the IPSec SA is established:

   1.  PANA client (PaC) and PAA mutually authenticate each other using
       EAP methods that derive the AAA-Key [I-D.ietf-eap-keying].
   2.  PaC learns the IP address of the Enforcement point (EP) during
       the PANA exchange.
   3.  PaC learns that the network uses IPSec [RFC2401] for securing the
       link between PaC and EP during the PANA exchange (PBR message).
   4.  PaC configures an IP address address before the PANA protocol
       begins (the pre-PANA Address (PRPA), see [I-D.ietf-pana-pana]).

   The IPSec IKE Action MIB module (IKEACTION-MIB) works within the
   framework of the IPSec SPD-MIB.  It can be referenced as an action by
   the SPD-MIB and is used to configure IKE negotiations between network
   devices.  Hence, together with the SPD-MIB, the IKEACTION-MIB module
   enables the PAA to configure IPSEC-based access control at the EP.

   The PAA is then responsible to communicate to EP the following
   information before IKE phase 1 exchange begins between PaC and EP:

   The IKE pre-shared key:
      To this end, the PAA must set a row in the IKE Credential Filter
      table of the IKEACTION-MIB.  This table defines filters, which can
      be used to match credentials of IKE peers, where the credentials
      in question have been obtained from an IKE phase 1 exchange.  They
      may be X.509 certificates, Kerberos tickets, or Pre-shared keys,
      etc.

El Mghazli, et al.        Expires June 1, 2005                 [Page 14]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   The PRPA of the PaC:
      An IP Header Filter of the SPD-MIB is used for configuring the SPD
      in a similar manner than what is described in Section 5.1.

   The Key-Id and PANA session ID:
      [I-D.ietf-pana-ipsec] states that Pac and EP should use the PANA
      session ID concatenated with the AAA-key as the value of the
      ID_KEY_ID in aggressive mode for establishing the phase 1 SA.
      Section 6 details usage examples that illustrate the way the
      IKEACTION-MIB is used for this purpose.

5.3  Notification of PaC presence

   The SPD-MIB provides a means to notify to the SNMP manager (PAA)
   information on packets matching/not matching the filters of given
   rule.  Such notification mechanisms and objects can be re-used for
   notifying the PAA that unauthorized packets are trying to pass
   through the EP.

   Section 7 defines new notifications, which aims at satisfying this
   requirement.  It re-uses existing notification variable objects
   pre-defined in the SPD-MIB.

   These "New PaC" notifications (panaNewPacIPNotification and
   panaNewPaCL2Notification) are triggered when the the EP detects
   traffic coming from an unauthorized source.

   If the traffic detected is an IP flow, the objects sent must include
   spdIPSourceType, spdIPSourceAddress, spdIPDestinationType, and
   spdIPDestinationAddress objects to indicate the packet source and
   destination of the packet that triggered the action.  Additionally,
   the spdIPInterfaceType and spdIPInterfaceAddress objects are included
   to indicate which interface the action was executed in association
   with and if the packet was inbound or outbound through the endpoint.
   See [I-D.ietf-ipsp-spd-mib] for further details.

   If the traffic detected is Link-layer traffic, the objects sent must
   include the index of the interface which detected such traffic and
   potentially the L2 address source of the traffic.  See Section 7 for
   further details.

El Mghazli, et al.        Expires June 1, 2005                 [Page 15]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

6.  EP Configuration Example

   Below are usage examples of the IPSec modules in the PANA context.

6.1  Common setup

   The "EndPoint to Group" table is used to map policy (groupings) onto
   an endpoint (EP-ADDR is the IP address) where traffic is to pass by.
   Any policy group assigned to an endpoint is then used to control
   access to the traffic passing by it.

   So far, we define below two policy groups at the EP interface
   ("EP-SPD-IN" and "EP-SPD-OUT").

   spdEndpointToGroupTable, row 1:
      spdEndGroupDirection = incoming;
      spdEndGroupIdentType = IPv4;
      spdEndGroupAddress   = EP-ADDR;
      spdEndGroupName      = "EP-SPD-IN";

   spdEndpointToGroupTable, row 2:
      spdEndGroupDirection = outgoing;
      spdEndGroupIdentType = IPv4;
      spdEndGroupAddress   = EP-ADDR;
      spdEndGroupName      = "EP-SPD-OUT";

   Within each of the policy group defined above, we define a sub-group
   (a compound filter) dedicated to the treatment of traffic that is
   allowed prior to any configuration.  The following configuration
   illustrates the incoming allowed unprotected traffic:

   spdGroupContentsTable, row 2:
      spdGroupContName          = "EP-SPD-IN";
      spdGroupContPriority      = '10';
      spdGroupContFilter        = spdTrueFilterInstance;
      spdGroupContComponentType = group;
      spdGroupContComponentName = "EP-ALLOWED-UNPROTECTED-IN";

   Within this sub-group, we define a rule (a sub-filter) dedicated to
   each allowed traffic types (namely PANA, ARP, IPv6 discover, DHCP,
   etc).  The following configuration illustrates the case of incoming
   DHCP traffic:

   spdGroupContentsTable, row 3:
      spdGroupContName          = "EP-ALLOWED-UNPROTECTED-IN";
      spdGroupContPriority      = '1';
      spdGroupContFilter        = spdIpHeaderFilterTable.10;

El Mghazli, et al.        Expires June 1, 2005                 [Page 16]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

      spdGroupContComponentType = rule;
      spdGroupContComponentName = "EP-DHCP-ACCEPT-IN";

   We define the corresponding filter in the IP Header filter table,
   which matches the DHCP packets:

   spdIpHeaderFilterTable, row 10:
      spdIpHeadFiltName        = "DHCP Filter";
      spdIpHeadFiltType        = { sourcePort ON, protocol ON };
      spdIpHeadFiltIPVersion   = v4;
      spdIpHeadFiltDstLowPort  = '546' (DHCP);
      spdIpHeadFiltDstHighPort = '547' (DHCP);
      spdIpHeadProtocol        = '17' (UDP);

   The "Rule Defininition" table links a rule with a given action in the
   SPD action MIB.  E.g.  the following entries links the filter defined
   above with the "accept" action statically defined in the SPD MIB
   (spdStaticActions.3).

   spdRuleDefinitionTable, row 1:
      spdRuleDefName          = "EP-DHCP-ACCEPT-IN";
      spdRuleDefDescription   = "Allow Incoming DHCP packets";
      spdRuleDefFilter        = spdTrueFilterInstance;
      spdRuleDefFilterNegated = false (default);
      spdRuleDefAction        = spdAcceptAction;

6.2  General IP-based Access Control

   In this section, we need to configure the SPD so that EP accepts IP
   packets coming from/going to the client 'PaC1'.

   Within the incoming policy group defined above ("EP-SPD-IN"), we
   define a rule dedicated to the treatment of packets coming from
   "PaC1" and the EP we are provisioning.

   spdGroupContentsTable, row 4:
      spdGroupContName          = "EP-SPD-IN";
      spdGroupContPriority      = '100';
      spdGroupContFilter        = spdIpHeaderFilterTable.1;
      spdGroupContComponentType = rule;
      spdGroupContComponentName = "EP-PaC1-ACCEPT-IN";

   We define the filter in the "IP Header filter" table, which matches
   IP packets coming from the PaC:

   spdIpHeaderFilterTable, row 1:
      spdIpHeadFiltName            = "PaC1-IP@ Filter SOURCE";

El Mghazli, et al.        Expires June 1, 2005                 [Page 17]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

      spdIpHeadFiltType            = { sourceAddress ON };
      spdIpHeadFiltIPVersion       = v4;
      spdIpHeadFiltSrcAddressBegin = 'PaC1-IP@';
      spdIpHeadFiltSrcAddressEnd   = 'PaC1-IP@';

   spdIpHeaderFilterTable, row 2:
      spdIpHeadFiltName            = "PaC1-IP@ Filter DEST";
      spdIpHeadFiltType            = { destAddress ON };
      spdIpHeadFiltIPVersion       = v4;
      spdIpHeadFiltSrcAddressBegin = 'PaC1-IP@';
      spdIpHeadFiltSrcAddressEnd   = 'PaC1-IP@';

   The following entries links the two filters defined above with the
   "accept" action.

   spdRuleDefinitionTable, row 2:
      spdRuleDefName          = "EP-PaC1-ACCEPT-IN";
      spdRuleDefDescription   = "Allow Incoming IP packets from PaC1";
      spdRuleDefFilter        = spdTrueFilterInstance;
      spdRuleDefFilterNegated = false (default);
      spdRuleDefAction        = spdAcceptAction;

   spdRuleDefinitionTable, row 3:
      spdRuleDefName          = "EP-PaC1-ACCEPT-OUT";
      spdRuleDefDescription   = "Allow Outgoing IP packets to PaC1";
      spdRuleDefFilter        = spdTrueFilterInstance;
      spdRuleDefFilterNegated = false (default);
      spdRuleDefAction        = spdAcceptAction;

   The same thing must be done for the outgoing direction and this
   results in a policy such that any packet coming from/going to the PaC
   is allowed to go through the EP (via EP-ADDR endpoint).

6.3  IPSec-based Access Control

   In this section we consider the case when IPSec is used to control
   access at the IP level.  In order to avoid many redundancies, the
   previous configuration set is still valid.  See below a usage example
   of IKEACTION-MIB.

   -- IKE Phase 1 configuration (agressive mode):

   We define a first-level filter in policy group "EP-SPD-IN" of the SPD
   MIB, using the "Group contents" table.  This filter isolates IKE
   phase 1 traffic coming to the EP on this interface:

   spdGroupContentsTable, row 6:

El Mghazli, et al.        Expires June 1, 2005                 [Page 18]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

      spdGroupContName          = "EP-SPD-IN";
      spdGroupContPriority      = '1';
      spdGroupContFilter        = ipiaIkePhase1Filter;
      spdGroupContComponentType = group;
      spdGroupContComponentName = "EP-IKE1-IN";

   Within this IKE-specific policy sub-group, we specify a second-level
   filter to apply for for the traffic coming from PaC1.

   spdGroupContentsTable, row 7:
      spdGroupContName          = "EP-IKE-Phase1-IN";
      spdGroupContPriority      = '1';
      spdGroupContFilter        = spdIpHeaderFilterTable.1;
      spdGroupContComponentType = group;
      spdGroupContComponentName = "EP-IKE1-PaC1-IN";

   The spdIpHeaderFilterTable.1 entry has been defined in the previous
   section.  Within the lattest sub-group we finally specify the rule to
   apply for the IKE traffic coming from PaC1 and matching the right
   identity (id_key_id).

   spdGroupContentsTable, row 8:
      spdGroupContName          = "EP-IKE1-PaC1-IN";
      spdGroupContPriority      = '1';
      spdGroupContFilter        = ipiaPeerIdentityFilterTable.1;
      spdGroupContComponentType = rule;
      spdGroupContComponentName = "PaC1-IKE1-RULE";

   The "Peer Identity Filter" table specifically informs the EP on the
   value of the idKeyId to use in IKE messages:

   ipiaPeerIdentityFilterTable, row 1:
      ipiaPeerIdFiltName          = "PaC1-IKE1-ID-FILTER";
      ipiaPeerIdFiltIdentityType  = id_Key_Id;
      ipiaPeerIdFiltIdentityValue = 'PANA-Session-Id|PANA-Key-Id';

   The "Rule Defininition" table links a rule with a given action in the
   IKE action MIB.  This action will be triggered upon reception at the
   EP of an IKE phase 1 packet coming from PaC1 and matching the right
   id_key_id.

   spdRuleDefinitionTable, row 4:
      spdRuleDefName          = "PaC1-IKE-RULE";
      spdRuleDefDescription   = "IPSec Access Control for PaC1";
      spdRuleDefFilter        = spdTrueFilterInstance;
      spdRuleDefFilterNegated = false (default);
      spdRuleDefAction        = ipiaIkeActionTable.1;

El Mghazli, et al.        Expires June 1, 2005                 [Page 19]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   The spdRuleDefAction attribute in the entry above points to a row in
   the ipiaIkeActionTable, defined below:

   ipiaIkeActionTable, row 1:
      ipiaIkeActName                 = "PaC1-IKE";
      ipiaIkeActParametersName       = "SA1-PaC1";
      ipiaIkeActThresholdDerivedKeys = '100' (default);
      ipiaIkeActExchangeMode         = aggressive;
      ipiaIkeActAgressiveModeGroupId = 'xxx' (Diffie-Hellman values);
      ipiaIkeActIdentityType         = id_Key_Id;
      ipiaIkeActIdentityContext      = "PANA";
      ipiaIkeActPeerName             = "PaC1";

   The following entry links together the "PaC1" identity with the
   corresponding credentials table entry:

   ipiaIkeIdentityTable, row 1:
      spdEndGroupIdentType      = IPv4;
      spdEndGroupAddress        = 'EP-ADDR';
      ipiaIkeActIdentityType    = id_Key_Id;
      ipiaIkeActIdentityContext = 'PANA';
      ipiaIkeIdCredentialName   = "PaC1-PSK";

   Finally, the pre-shared key derivated at the PAA is set in the IPSA
   Credentials table:

   ipsaCredentialTable, row 1:
      ipsaCredName = "PaC1-PSK";
      ipsaCredType = sharedSecret;
      ipsaCredCredential = 'PSK-derived-at-the-PAA';
      ipsaCredSize = 'xxx';
      ipsaMgnName = "xxx";
      ipsaRemoteID = 'PaC1';

   The Ike Action entry (above) is indexed by a name (ipiaIkaActName
   attribute), which is used as the primary index into the
   ipiaIkeActionProposalsTable.  The secondary index is a priority,
   which allows ordering of the proposals that will be sent to the peer
   (or accepted from the peer).

   ipiaIkeActionProposalsTable, row 1:
      ipiaIkeActPropName     = "PaC1-IKE-PROP1";
      ipiaIkeActPropPriority = '1';

   The ipiaIkeActPropName points to a row in the ipiaIkeProposalsTable,
   which contains the actual IKE parameters for the Phase 1 exchanges:

   ipiaIkeProposalsTable, row 1:

El Mghazli, et al.        Expires June 1, 2005                 [Page 20]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

      ipiaIkeActPropName              = "PaC1-IKE-PROP1";
      ipiaIkePropLifetimeDerivedKeys  = xxx;
      ipiaIkePropCipherAlgorithm      = 3DES;
      ipiaIkePropCipherKeyLength      = xxx;
      ipiaIkePropHashAlgorithm        = HMAC-SHA1;
      ipiaIkePropPrfAlgorithm         = xxx;
      ipiaIkePropVendorId             = xxx;
      ipiaIkePropDhGroup              = 2;
      ipiaIkePropAuthenticationMethod = xxx;
      ipiaIkePropMaxLifetimeSecs      = xxx;
      ipiaIkePropMaxLifetimeKB        = xxx;

   There is a similar hierarchy for the proposals, which are used for
   Phase 2 negotiations, and result in a Phase 2 SA being created, upon
   successful negotiations.  The parameters would be set up in the
   ipiaIpsecActionTable, ipiaIpsecProposalsTable and
   ipiaIpsecTransformsTable, along with the necessary related tables.
   One would then need a rule to trigger the row in the
   ipiaIpsecActionTable.  See for further details on the IPSP MIBs
   usage.

El Mghazli, et al.        Expires June 1, 2005                 [Page 21]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

7.  PANA extension to the IPSec SPD MIB

   Many existing IPSec MIB objects defined in the IPSec Configuration
   MIB modules can be efficiently re-used for the PANA-specific needs.
   This is detailed in Section 5.

   The following sections define additional PANA-specific objects that
   extend the IPSec MIB module in order to entirely satisfy the PAA-EP
   interface requirements.

7.1  PANA MIB Overview

   o  Link-Layer filter table
   o  New PaC notification

7.2  PANA-specific objects definition

       	PANA-EP-MIB DEFINITIONS ::= BEGIN

   	    IMPORTS

   	    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Integer32
   	    FROM SNMPv2-SMI

   	    RowStatus, PhysAddress, StorageType, TimeStamp
   	    FROM SNMPv2-TC

   	    MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
   	    FROM SNMPv2-CONF

   	    SnmpAdminString
   	    FROM SNMP-FRAMEWORK-MIB

   	    InterfaceIndex
   	    FROM IF-MIB

   	    spdMIB, spdActionExecuted, spdIPInterfaceType, spdIPInterfaceAddress,
   	    spdIPSourceType, spdIPSourceAddress, spdIPDestinationType,
   	    spdIPDestinationAddress, spdPacketDirection
   	    FROM IPSEC-SPD-MIB;

   	    -- Module identity
   	    --

   	    panaMIB MODULE-IDENTITY
   	    LAST-UPDATED
   	    "200410220000Z"            -- 22 October 2004

El Mghazli, et al.        Expires June 1, 2005                 [Page 22]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   	    ORGANIZATION
   	    "IETF PANA Working Group"
   	    CONTACT-INFO
   	    "Yacine El Mghazli
   	     Alcatel
   	     91460 Marcoussis, France
   	     Phone: +33 1 69 63 41 87
   	     Email: [email-masked]"
   	    DESCRIPTION
   	    "The MIB module for defining additional PANA-specific objects to
   	     the IPSec SPD MIB. Copyright (C) The Internet Society (2003).
   	     This version of this MIB module is part of RFC XXXX, see the
   	     RFC itself for full legal notices."

   	    -- Revision History
   	    REVISION
   	    "200410220000Z"            -- 22 October 2004
   	    DESCRIPTION
   	    "Version 02, draft-ietf-pana-snmp-02.txt"
   	    REVISION
   	    "200402050000Z"            -- 05 February 2004
   	    DESCRIPTION
   	    "Version 01, draft-yacine-pana-paa2ep-snmp-01.txt"
   	    REVISION
   	    "200310310000Z"            -- 31 October 2003
   	    DESCRIPTION
   	    "Initial version, draft-yacine-pana-paa2ep-snmp-00.txt"
   	    ::= { spdMIB  99999999 } -- XXX to be assigned by IANA

   	    --
   	    -- groups of related objects
   	    --

   	    panaConfigObjects         OBJECT IDENTIFIER
   	    ::= { panaMIB 1 }
   	    panaNotificationObjects   OBJECT IDENTIFIER
   	    ::= { panaMIB 2}
   	    panaConformanceObjects    OBJECT IDENTIFIER
   	    ::= { panaMIB 3 }

   	    --
   	    -- Textual Conventions
   	    --

   	    -- TBD.

   	    --
   	    -- PANA Additional Filters Objects

El Mghazli, et al.        Expires June 1, 2005                 [Page 23]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   	    --

   	    --
   	    -- The Link-layer Filter Table
   	    --

   	    panaL2FilterTable OBJECT-TYPE
   	    SYNTAX      SEQUENCE OF PanaL2FilterEntry
   	    MAX-ACCESS  not-accessible
   	    STATUS      current
   	    DESCRIPTION
   	    "Link-layer filter definitions."
   	    ::= { panaConfigObjects 1 }

   	    panaL2FilterEntry OBJECT-TYPE
   	    SYNTAX      PanaL2FilterEntry
   	    MAX-ACCESS  not-accessible
   	    STATUS      current
   	    DESCRIPTION
   	    "An entry in the Link-layer filter table."
   	    INDEX       { panaL2FiltEpIfIndex }
   	    ::= { panaL2FilterTable 1 }

   	    PanaL2FilterEntry ::= SEQUENCE {
   		panaL2FiltEpIfIndex 		InterfaceIndex,
   	    panaL2FiltAddr              PhysAddress,
   	    panaL2FiltLastChanged       TimeStamp,
   	    panaL2FiltStorageType       StorageType,
   	    panaL2FiltRowStatus         RowStatus
   	    }

   	    panaL2FiltEpIfIndex OBJECT-TYPE
   	    SYNTAX         InterfaceIndex
   	    MAX-ACCESS     read-create
   	    STATUS         current
   	    DESCRIPTION
   	    "The index identifying the EP interface where the filter
   		policy must be enforced on."
   	    ::= { panaL2FilterEntry 1 }

   	    panaL2FiltAddr OBJECT-TYPE
   	    SYNTAX         PhysAddress
   	    MAX-ACCESS     read-create
   	    STATUS         current
   	    DESCRIPTION
   	    "The authorized device Link-layer address (DI). For

El Mghazli, et al.        Expires June 1, 2005                 [Page 24]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   	    example, for a 802.x interface, this object normally
   	    contains a MAC address. For interfaces which do not have such
   		an address (e.g., a serial line), this object should contain
   		an octet string of zero length."
   	    ::= { panaL2FilterEntry 2 }

   	    panaL2FiltLastChanged OBJECT-TYPE
   	    SYNTAX      TimeStamp
   	    MAX-ACCESS  read-only
   	    STATUS      current
   	    DESCRIPTION
   	    "The value of sysUpTime when this row was last modified or
   	    created either through SNMP SETs or by some other external
   	    means."
   	    ::= { panaL2FilterEntry 3 }

   	    panaL2FiltStorageType OBJECT-TYPE
   	    SYNTAX      StorageType
   	    MAX-ACCESS  read-create
   	    STATUS      current
   	    DESCRIPTION
   	    "The storage type for this row. Rows in this table which were
   	    created through an external process may have a storage type
   	    of readOnly or permanent."
   	    DEFVAL { nonVolatile }
   	    ::= { panaL2FilterEntry 4 }

   	    panaL2FiltRowStatus OBJECT-TYPE
   	    SYNTAX      RowStatus
   	    MAX-ACCESS  read-create
   	    STATUS      current
   	    DESCRIPTION
   	    "This object indicates the conceptual status of this row."
   	    ::= { panaL2FilterEntry 5 }

   	    --
   	    --
   	    -- Notification objects information
   	    --
   	    --

   	    panaNotificationVariables OBJECT IDENTIFIER ::=
   	    { panaNotificationObjects 1 }

   	    panaNotifications OBJECT IDENTIFIER ::=
   	    { panaNotificationObjects 0 }

El Mghazli, et al.        Expires June 1, 2005                 [Page 25]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   	    panaEpIfIndex OBJECT-TYPE
   	    SYNTAX      InterfaceIndex
   	    MAX-ACCESS  accessible-for-notify
   	    STATUS      current
   	    DESCRIPTION
   	    "Contains the interface index on which the packet triggered
   	    the notification in question."
   	    ::= { panaNotificationVariables 1 }

   	    panaL2SourceAddress OBJECT-TYPE
   	    SYNTAX      PhysAddress
   	    MAX-ACCESS  accessible-for-notify
   	    STATUS      current
   	    DESCRIPTION
   	    "Contains the source Link layer address of the packet which
   	    triggered the notification in question. For
   	    example, for a 802.x frame, this object normally
   	    contains a MAC address. For interfaces which do not have such
           an address (e.g., a serial line), this object should contain
           an octet string of zero length. "
   	    ::= { panaNotificationVariables 2 }

   	    panaNewPacIPNotification NOTIFICATION-TYPE
   	    OBJECTS {
   	      spdActionExecuted,
   	      spdIPInterfaceType,
   	      spdIPInterfaceAddress,
   	      spdIPSourceType,
   	      spdIPSourceAddress,
   	      spdIPDestinationType,
   	      spdIPDestinationAddress}
   	    STATUS  current
   	    DESCRIPTION
   	    "Notification that EP detected IP traffic coming from an
   	    unauthorized source."
   	    ::= { panaNotifications 1 }

   	    panaNewPacL2Notification NOTIFICATION-TYPE
   	    OBJECTS {
   	      spdActionExecuted,
   	      panaEpIfIndex,
   	      panaL2SourceAddress
   	    }
   	    STATUS  current
   	    DESCRIPTION
   	    "Notification that EP detected L2 traffic coming from an

El Mghazli, et al.        Expires June 1, 2005                 [Page 26]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   	    unauthorized source. "
   	    ::= { panaNotifications 2 }

   	    --
   	    --
   	    -- Conformance information
   	    --
   	    --

   	    panaGroups OBJECT IDENTIFIER
   	    ::= { panaConformanceObjects 1 }
   	    panaCompliances OBJECT IDENTIFIER
   	    ::= { panaConformanceObjects 2 }

   	    --
   	    -- Compliance Groups Definitions
   	    --

   	    panaL2FilterGroup OBJECT-GROUP
   	    OBJECTS {
   	      panaL2FiltAddr,
   	      panaL2FiltLastChanged,
   	      panaL2FiltStorageType,
   	      panaL2FiltRowStatus }
   	    STATUS current
   	    DESCRIPTION
   	    "The Link-layer Filter Group."
   	    ::= { panaGroups 1 }

   	    panaNewPacL2NotificationObjectsGroup OBJECT-GROUP
   	    OBJECTS {
   	      panaEpIfIndex,
   	      panaL2SourceAddress}
   	    STATUS current
   	    DESCRIPTION
   	    "PaC Presence Notification Objects Group."
   	    ::= { panaGroups 2 }

   	    panaNewPacNotificationGroup NOTIFICATION-GROUP
   	    NOTIFICATIONS {
   	      panaNewPacIPNotification,
   	      panaNewPacL2Notification}
   	    STATUS current
   	    DESCRIPTION
   	    "PaC Presence Notification Group."
   	    ::= { panaGroups 3 }

El Mghazli, et al.        Expires June 1, 2005                 [Page 27]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   	    --
   	    -- Compliance statements
   	    --

   	    panaFilterCompliance MODULE-COMPLIANCE
   	    STATUS      current
   	    DESCRIPTION
   	    "The compliance statement for SNMP entities that support
   	    PANA DI-based filtering."

   	    MODULE -- This Module

   	    MANDATORY-GROUPS { panaL2FilterGroup }

   	    OBJECT      panaL2FiltRowStatus
   	    SYNTAX      RowStatus { active(1), createAndGo(4), destroy(6) }
   	    DESCRIPTION
   	    "Support of the values notInService(2), notReady(3),
   	    and createAndWait(5) is not required."

   	    OBJECT      panaL2FiltLastChanged
   	    MIN-ACCESS  not-accessible
   	    DESCRIPTION
   	    "This object not required for compliance."

   	    MODULE IPSEC-SPD-MIB

   	    MANDATORY-GROUPS {
   	      spdEndpointGroup,
   	      spdGroupContentsGroup,
   	      spdRuleDefinitionGroup,
   	      spdIPHeaderFilterGroup,
   	      spdStaticFilterGroup,
   	      spdStaticActionGroup }

   	    GROUP spdIpsecSystemPolicyNameGroup
   	    DESCRIPTION
   	    "This group is mandatory for IPsec Policy
   	    implementations which support a system policy group
   	    name."

   	    GROUP spdCompoundFilterGroup
   	    DESCRIPTION
   	    "This group is mandatory for IPsec Policy
   	    implementations which support compound filters."

   	    GROUP  spdCompoundActionGroup

El Mghazli, et al.        Expires June 1, 2005                 [Page 28]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   	    DESCRIPTION
   	    "This group is mandatory for IPsec Policy
   	    implementations which support compound actions."

   	    OBJECT      spdEndGroupRowStatus
   	    SYNTAX      RowStatus { active(1), createAndGo(4), destroy(6) }
   	    DESCRIPTION
   	    "Support of the values notInService(2), notReady(3),
   	    and createAndWait(5) is not required."

   	    OBJECT      spdEndGroupLastChanged
   	    MIN-ACCESS  not-accessible
   	    DESCRIPTION
   	    "This object not required for compliance."

   	    OBJECT      spdGroupContComponentType
   	    SYNTAX      INTEGER { rule(2) }
   	    DESCRIPTION
   	    "Support of the value group(1) is only required for
   	    implementations which support Policy Groups within
   	    Policy Groups."

   	    OBJECT      spdGroupContRowStatus
   	    SYNTAX      RowStatus { active(1), createAndGo(4), destroy(6) }
   	    DESCRIPTION
   	    "Support of the values notInService(2), notReady(3),
   	    and createAndWait(5) is not required."

   	    OBJECT      spdGroupContLastChanged
   	    MIN-ACCESS  not-accessible
   	    DESCRIPTION
   	    "This object not required for compliance."

   	    OBJECT      spdRuleDefRowStatus
   	    SYNTAX      RowStatus { active(1), createAndGo(4), destroy(6) }
   	    DESCRIPTION
   	    "Support of the values notInService(2), notReady(3),
   	    and createAndWait(5) is not required."

   	    OBJECT      spdRuleDefLastChanged
   	    MIN-ACCESS  not-accessible
   	    DESCRIPTION
   	    "This object not required for compliance."

   	    OBJECT      spdCompFiltRowStatus
   	    SYNTAX      RowStatus { active(1), createAndGo(4), destroy(6) }
   	    DESCRIPTION
   	    "Support of the values notInService(2), notReady(3),

El Mghazli, et al.        Expires June 1, 2005                 [Page 29]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   	    and createAndWait(5) is not required."

   	    OBJECT      spdCompFiltLastChanged
   	    MIN-ACCESS  not-accessible
   	    DESCRIPTION
   	    "This object not required for compliance."

   	    OBJECT      spdSubFiltRowStatus
   	    SYNTAX      RowStatus { active(1), createAndGo(4), destroy(6) }
   	    DESCRIPTION
   	    "Support of the values notInService(2), notReady(3),
   	    and createAndWait(5) is not required."

   	    OBJECT      spdSubFiltLastChanged
   	    MIN-ACCESS  not-accessible
   	    DESCRIPTION
   	    "This object not required for compliance."

   	    OBJECT      spdIpHeadFiltIPVersion
   	    SYNTAX      InetAddressType { ipv4(1), ipv6(2) }
   	    DESCRIPTION
   	    "Only the ipv4 and ipv6 values make sense for this
   	    object."

   	    OBJECT      spdIpHeadFiltRowStatus
   	    SYNTAX      RowStatus { active(1), createAndGo(4), destroy(6) }
   	    DESCRIPTION
   	    "Support of the values notInService(2), notReady(3),
   	    and createAndWait(5) is not required."

   	    OBJECT      spdIpHeadFiltLastChanged
   	    MIN-ACCESS  not-accessible
   	    DESCRIPTION
   	    "This object not required for compliance."

   	    OBJECT      spdCompActRowStatus
   	    SYNTAX      RowStatus { active(1), createAndGo(4), destroy(6) }
   	    DESCRIPTION
   	    "Support of the values notInService(2), notReady(3),
   	    and createAndWait(5) is not required."

   	    OBJECT      spdCompActLastChanged
   	    MIN-ACCESS  not-accessible
   	    DESCRIPTION
   	    "This object not required for compliance."

   	    OBJECT      spdSubActRowStatus
   	    SYNTAX      RowStatus { active(1), createAndGo(4), destroy(6) }

El Mghazli, et al.        Expires June 1, 2005                 [Page 30]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   	    DESCRIPTION
   	    "Support of the values notInService(2), notReady(3),
   	    and createAndWait(5) is not required."

   	    OBJECT      spdSubActLastChanged
   	    MIN-ACCESS  not-accessible
   	    DESCRIPTION
   	    "This object not required for compliance."

   	    ::= { panaCompliances 1 }

   	    panaNewPacNotificationCompliance MODULE-COMPLIANCE
   	    STATUS      current
   	    DESCRIPTION
   	    "The compliance statement for SNMP entities that support
   	    new PaC presence Notification."

   	    MODULE -- This Module

   	    MANDATORY-GROUPS {
   	      panaNewPacL2NotificationObjectsGroup,
   	      panaNewPacNotificationGroup
   	    }

   	    MODULE IPSEC-SPD-MIB

   	    MANDATORY-GROUPS { spdActionLoggingObjectGroup }

   	    ::= { panaCompliances 2 }

   	    END

El Mghazli, et al.        Expires June 1, 2005                 [Page 31]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

8.  Open Issues

8.1  Security Issue on PaC presence notification

   It has been reported that the PANA-specific notification of PaC
   presence could be used to overwhelm an SNMP application, thus
   creating a DoS attack on the management of the network.  A attacker
   could detect that such notifications are sent by multiple devices,
   and the attacker could deliberately send lots of traffic through the
   devices.

8.2  MIB usage example

   The MIB usage example (Section 6) needs to be further developped with
   the support of the IPSP working group.

8.3  Link-layer protection support

   [I-D.ietf-pana-framework] envisages the case, where enabling
   link-layer ciphering (e.g.  [802.11i]) or network-layer ciphering
   might rely on PANA authentication.  The user and network then have to
   make sure an appropriate EAP method that can generate required keying
   materials is used.  Once the keying material is available, it needs
   to be provided to the EP(s) for use with ciphering.

   Network-layer ciphering configuration, i.e., IPsec, including IKE
   configuration is fully supported in the present document.

   However link-layer ciphers control is not supported yet.  The PANA
   working group must define the L2 techniques supported (e.g.[802.11i])
   for realizing this feature and the present document should take it
   into account.

El Mghazli, et al.        Expires June 1, 2005                 [Page 32]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

9.  Security Considerations

   The MIB defined in the present document relates to a system which
   will provide network access.  As such, improper manipulation of the
   objects represented by this MIB may result in denial of service to a
   large number of end-users.  In addition, manipulation of the
   panaL2FilterTable and spdIpHeaderFilterTable may allow an end-user to
   gain network access, spoof their IP addresses, change the authorized
   device identifiers, or affect other end-users in either a positive or
   negative manner.

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:

   o  The use of panaIPL2FilterTable to specify which Link-layer
      addresses are authorized to access the network is considered to be
      only limited protection and does not protect against attacks which
      spoof the management station's IP address.  The use of SNMPv3
      security is mandated.  Specifically, SNMPv3 VACM and USM MUST be
      used with any v3 agent which implements this MIB.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

El Mghazli, et al.        Expires June 1, 2005                 [Page 33]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

10.  Acknowledgements

   Many thanks to Robert Story, who provided very helpful
   recommendations on the IPSP MIBs usage.

   This document originaly leverages on similar works done in the MIDCOM
   working group.  Thanks to the authors of those IDs.  Thanks to Thomas
   Moore and Olivier Marce for their grateful help during the edition of
   this document.

El Mghazli, et al.        Expires June 1, 2005                 [Page 34]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

11.  References

11.1  Normative References

   [I-D.ietf-pana-pana]
              Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", draft-ietf-pana-pana-06 (work in
              progress), October 2004.

   [I-D.ietf-pana-requirements]
              Yegin, A. and Y. Ohba, "Protocol for Carrying
              Authentication for Network Access (PANA)Requirements",
              draft-ietf-pana-requirements-09 (work in progress), August
              2004.

   [I-D.ietf-pana-ipsec]
              Parthasarathy, M., "PANA enabling IPsec based Access
              Control", draft-ietf-pana-ipsec-04 (work in progress),
              September 2004.

   [I-D.ietf-pana-threats-eval]
              Parthasarathy, M., "Protocol for Carrying Authentication
              and Network Access Threat Analysis and  Security
              Requirements", draft-ietf-pana-threats-eval-07 (work in
              progress), August 2004.

   [I-D.ietf-pana-framework]
              Jayaraman, P., "PANA Framework",
              draft-ietf-pana-framework-02 (work in progress), September
              2004.

   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

   [I-D.ietf-ipsp-spd-mib]
              Hardaker, W., "IPsec Security Policy Database
              Configuration MIB", draft-ietf-ipsp-spd-mib-01 (work in
              progress), October 2004.

   [I-D.ietf-ipsp-ikeaction-mib]
              Hardaker, W., "IPsec Security Policy IKE Action MIB",
              draft-ietf-ipsp-ikeaction-mib-01 (work in progress),
              October 2004.

   [I-D.ietf-aaa-diameter-cc]
              Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H.

El Mghazli, et al.        Expires June 1, 2005                 [Page 35]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

              Hakala, "Diameter Credit-control Application",
              draft-ietf-aaa-diameter-cc-06 (work in progress), August
              2004.

   [I-D.ietf-aaa-eap]
              Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application",
              draft-ietf-aaa-eap-10 (work in progress), November 2004.

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-04 (work in
              progress), November 2004.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC3410]  Case, J., Mundy, R., Partain, D. and B. Stewart,
              "Introduction and Applicability Statements for
              Internet-Standard Management Framework", RFC 3410,
              December 2002.

   [RFC3411]  Harrington, D., Presuhn, R. and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2578]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of
              Management Information Version 2 (SMIv2)", STD 58, RFC
              2578, April 1999.

   [RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
              McCloghrie, K., Rose, M. and S. Waldbusser, "Textual
              Conventions for SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D. and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

El Mghazli, et al.        Expires June 1, 2005                 [Page 36]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [802.11i]  IEEE P802, "Wireless MAC and PHY specifications, MAC
              security enhancements", IEEE 802.11i, July 2004.

11.2  Informative References

   [I-D.yacine-pana-paa2ep-prot-eval]
              Mghazli, Y., "PANA PAA-EP protocol considerations",
              draft-yacine-pana-paa2ep-prot-eval-00 (work in progress),
              October 2003.

   [I-D.yacine-pana-paa-ep-reqs]
              Mghazli, Y., "PANA PAA-EP Protocol Requirements",
              draft-yacine-pana-paa-ep-reqs-00 (work in progress),
              October 2003.

Authors' Addresses

   Yacine El Mghazli (Editor)
   Alcatel
   Route de Nozay
   Marcoussis  91460
   France

   EMail: [email-masked]

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1, Telcordia Drive
   Piscataway, NJ  08854
   USA

   EMail: [email-masked]

El Mghazli, et al.        Expires June 1, 2005                 [Page 37]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

   Julien Bournelle
   GET/INT
   9, rue Charles Fourier
   Evry  91011
   France

   EMail: [email-masked]

El Mghazli, et al.        Expires June 1, 2005                 [Page 38]

Internet-Draft      SNMP usage for PAA-EP interface        December 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

El Mghazli, et al.        Expires June 1, 2005                 [Page 39]


_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

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