Subject: [Fwd: [Pana] I-D ACTION:draft-ietf-pana-snmp-03.txt]

From: [email-masked]
Date: Thu, 24 Feb 2005 11:11:13 +0100

* the 03-from-02.diff.html file is attached.
* thanks to robert story and david perkins for their valuable support.

thanks,
yacine

-------- Original Message --------
Subject: [Pana] I-D ACTION:draft-ietf-pana-snmp-03.txt
Date: Tue, 22 Feb 2005 16:08:42 -0500
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Protocol for carrying Authentication 
for Network Access Working Group of the IETF.

	Title		: SNMP usage for PAA-2-EP interface
	Author(s)	: Y. Mghazli, et al.
	Filename	: draft-ietf-pana-snmp-03.txt
	Pages		: 41
	Date		: 2005-2-22
	
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 (PaC) successfully authenticates itself
    to the PAA, EP(s) (e.g., access routers) will need to be suitably
    notified. The PANA working group mandates the use of Simple Network
    Management Protocol (SNMP) 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 SNMP as the PAA-2-EP protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pana-snmp-03.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pana-snmp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pana-snmp-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

draft-ietf-pana-snmp-02.txt

draft-ietf-pana-snmp-03.txt

PANA Working Group Y. El Mghazli

PANA Working Group Y. El Mghazli

Internet-Draft Alcatel

Internet-Draft Alcatel

Expires: April 22, 2005 Y. Ohba

Expires: August 25, 2005 Y. Ohba

Toshiba

Toshiba

J. Bournelle

J. Bournelle

GET/INT

GET/INT

October 22, 2004

February 21, 2005

SNMP usage for PAA-EP interface

SNMP usage for PAA-EP interface

draft-ietf-pana-snmp-02

draft-ietf-pana-snmp-03

Status of this Memo

Status of this Memo

This document is an Internet-Draft and is subject to all provisions

This document is an Internet-Draft and is subject to all provisions

of section 3 of RFC 3667. By submitting this Internet-Draft, each

of Section 3 of RFC 3667. By submitting this Internet-Draft, each

author represents that any applicable patent or other IPR claims of

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 is aware have been or will be disclosed, and any of

which he or she become aware will be disclosed, in accordance with

which he or she become aware will be disclosed, in accordance with

RFC 3668.

RFC 3668.

Internet-Drafts are working documents of the Internet Engineering

Internet-Drafts are working documents of the Internet Engineering

Task Force (IETF), its areas, and its working groups. Note that

Task Force (IETF), its areas, and its working groups. Note that

other groups may also distribute working documents as

other groups may also distribute working documents as

Internet-Drafts.

Internet-Drafts.

skipping to change at page 1, line 39

skipping to change at page 1, line 39

and may be updated, replaced, or obsoleted by other documents at any

and may be updated, replaced, or obsoleted by other documents at any

time. It is inappropriate to use Internet-Drafts as reference

time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at

The list of current Internet-Drafts can be accessed at

http://www.ietf.org/ietf/1id-abstracts.txt.

http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at

The list of Internet-Draft Shadow Directories can be accessed at

http://www.ietf.org/shadow.html.

http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 22, 2005.

This Internet-Draft will expire on August 25, 2005.

Copyright Notice

Copyright Notice

Copyright (C) The Internet Society (2004).

Copyright (C) The Internet Society (2005).

Abstract

Abstract

The PANA Authentication Agent (PAA) does not necessarily act as an

The PANA Authentication Agent (PAA) does not necessarily act as an

Enforcement Point (EP) to prevent unauthorized access or usage of the

Enforcement Point (EP) to prevent unauthorized access or usage of the

network. When a PANA Client successfully authenticates itself to the

network. When a PANA Client successfully authenticates itself to the

PAA, EP(s) (e.g., access routers) will need to be suitably notified.

PAA, EP(s) (e.g., access routers) will need to be suitably notified.

The PANA working group mandates the use of Simple Network Management

The PANA working group mandates the use of Simple Network Management

Protocol Version 3 (SNMPv3) to deliver the authorization information

Protocol Version 3 (SNMPv3) to deliver the authorization information

to one or more EPs when the PAA is separated from EPs.

to one or more EPs when the PAA is separated from EPs.

The present document provides the necessary information and

The present document provides the necessary information and

extensions needed to use SNMPv3 as the PAA-EP protocol.

extensions needed to use SNMPv3 as the PAA-EP protocol.

Table of Contents

Table of Contents

1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3

1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3

skipping to change at page 2, line 15

skipping to change at page 2, line 15

The PANA working group mandates the use of Simple Network Management

The PANA working group mandates the use of Simple Network Management

Protocol Version 3 (SNMPv3) to deliver the authorization information

Protocol Version 3 (SNMPv3) to deliver the authorization information

to one or more EPs when the PAA is separated from EPs.

to one or more EPs when the PAA is separated from EPs.

The present document provides the necessary information and

The present document provides the necessary information and

extensions needed to use SNMPv3 as the PAA-EP protocol.

extensions needed to use SNMPv3 as the PAA-EP protocol.

Table of Contents

Table of Contents

1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3

1. Terminology and Definitions . . . . . . . . . . . . . . . . . 3

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 PAA/EP separation context . . . . . . . . . . . . . . . . 4

2.1 PAA/EP separation context . . . . . . . . . . . . . . . . 5

2.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. The Internet-Standard Management Framework . . . . . . . . . . 6

3. The Internet-Standard Management Framework . . . . . . . . . . 7

4. SNMP Applicability with the PANA framework . . . . . . . . . . 7

4. SNMP Applicability with the PANA framework . . . . . . . . . . 8

4.1 SNMPv3 General applicability . . . . . . . . . . . . . . . 7

4.1 SNMPv3 General applicability . . . . . . . . . . . . . . . 8

4.2 Compliancy of SNMP against the PANA requirements . . . . . 8

4.2 Compliancy of SNMP against the PANA requirements . . . . . 9

4.2.1 Authorization Consideration . . . . . . . . . . . . . 8

4.2.1 Authorization Consideration . . . . . . . . . . . . . 9

4.2.2 PAA-EP relation . . . . . . . . . . . . . . . . . . . 9

4.2.2 PAA-EP relation . . . . . . . . . . . . . . . . . . . 10

4.2.3 Secure Communication . . . . . . . . . . . . . . . . . 9

4.2.3 Secure Communication . . . . . . . . . . . . . . . . . 10

4.2.4 Notification of PaC presence . . . . . . . . . . . . . 9

4.2.4 Notification of PaC presence . . . . . . . . . . . . . 10

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

4.2.5 Accounting Consideration . . . . . . . . . . . . . . . 11

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

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

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

5. Applicability of IPSec configuration MIBs . . . . . . . . . . 13

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

5.1 General Access Control . . . . . . . . . . . . . . . . . . 13

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

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

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

5.3 Notification of PaC presence . . . . . . . . . . . . . . . 16

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

6. EP Configuration Example . . . . . . . . . . . . . . . . . . . 18

6.1 General IP-based Access Control . . . . . . . . . . . . . 16

6.1 Common setup . . . . . . . . . . . . . . . . . . . . . . . 18

6.2 IPSec-based Access Control . . . . . . . . . . . . . . . . 17

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

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

6.3 IPSec-based Access Control . . . . . . . . . . . . . . . . 20

7.1 PANA MIB Overview . . . . . . . . . . . . . . . . . . . . 20

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

7.2 PANA-specific objects definition . . . . . . . . . . . . . 20

7.1 PANA MIB Overview . . . . . . . . . . . . . . . . . . . . 24

8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 30

7.2 PANA-specific objects definition . . . . . . . . . . . . . 24

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

8. Security Considerations . . . . . . . . . . . . . . . . . . . 34

8.2 MIB usage example . . . . . . . . . . . . . . . . . . . . 30

9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36

8.3 Link-layer protection support . . . . . . . . . . . . . . 30

10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37

9. Security Considerations . . . . . . . . . . . . . . . . . . . 31

10.1 Normative References . . . . . . . . . . . . . . . . . . . 37

10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32

10.2 Informative References . . . . . . . . . . . . . . . . . . 39

11. References . . . . . . . . . . . . . . . . . . . . . . . . . 33

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39

11.1 Normative References . . . . . . . . . . . . . . . . . . . . 33

Intellectual Property and Copyright Statements . . . . . . . . 41

11.2 Informative References . . . . . . . . . . . . . . . . . . . 35

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 35

Intellectual Property and Copyright Statements . . . . . . . . 37

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 4, line 5

skipping to change at page 4, line 5

EP (Enforcement Point):

EP (Enforcement Point):

A node on the access network where per-packet enforcement policies

A node on the access network where per-packet enforcement policies

(i.e., filters) are applied on the inbound and outbound traffic of

(i.e., filters) are applied on the inbound and outbound traffic of

client devices. The EP uses non-cryptographic or cryptographic

client devices. The EP uses non-cryptographic or cryptographic

filters to selectively allow and discard data packets. These

filters to selectively allow and discard data packets. These

filters may be applied at the link-layer or the IP-layer. An EP

filters may be applied at the link-layer or the IP-layer. An EP

learns the attributes of the authorized clients (DI and

learns the attributes of the authorized clients (DI and

(optionally) cryptographic keys) from the PAA.

(optionally) cryptographic keys) from the PAA.

Authentication Server (AS):

The server implementation that is in charge of verifying the

credentials of a PaC that is requesting the network access

service. The AS receives requests from the PAA on behalf of the

PaCs, and responds with the result of verification together with

the authorization parameters (e.g., allowed bandwidth, IP

configuration, etc). The AS might be hosted on the same node as

the PAA, on a dedicated node on the access network, or on a

central server somewhere in the Internet.

2. Introduction

2. Introduction

2.1 PAA/EP separation context

2.1 PAA/EP separation context

PANA enables access control by identifying legitimate clients and

PANA enables access control by identifying legitimate clients and

generating filtering information for access control mechanisms.

generating filtering information for access control mechanisms.

[I-D.ietf-pana-framework] defines a general AAA and access control

[I-D.ietf-pana-framework] defines a general AAA and access control

framework. The PANA protocol itself provides client authentication

framework. The PANA protocol itself provides client authentication

and authorization functionality for securing network access. The

and authorization functionality for securing network access. The

other component of a complete solution is the access control which

other component of a complete solution is the access control which

skipping to change at page 5, line 18

skipping to change at page 6, line 18

PANA authentication, a secure association protocol runs between the

PANA authentication, a secure association protocol runs between the

PaC and the EP. The PaC should already have the input parameters to

PaC and the EP. The PaC should already have the input parameters to

this process as a result of the successful PANA exchange. Similarly,

this process as a result of the successful PANA exchange. Similarly,

the EP should have obtained them from the PAA via SNMP. Secure

the EP should have obtained them from the PAA via SNMP. Secure

association exchange produces the required security associations

association exchange produces the required security associations

between the PaC and the EP to enable per-packet protection.

between the PaC and the EP to enable per-packet protection.

Finally data traffic can start flowing from and to the newly

Finally data traffic can start flowing from and to the newly

authorized PaC.

authorized PaC.

In this document, it is assumed that PAA and EP are pre-configured to

be able to communicate each other with a required security

association. In case where dynamic discovery is needed for PAA and

EP to know each other's address, then SNMPv3 engine-id discovery

could be used. Such dynamic discovery is out of scope of this

document.

2.2 Scope

2.2 Scope

Section 3 gives references for the SNMP framework.

Section 3 gives references for the SNMP framework.

Section 4 provides a general statement with regards to the

Section 4 provides a general statement with regards to the

applicability of SNMP as the PAA-EP protocol.

applicability of SNMP as the PAA-EP protocol.

IPSec MIB modules were found to have general applicability and

IPSec MIB modules were found to have general applicability and

varying levels of re-usability for PANA EP configuration using SNMP.

varying levels of re-usability for PANA EP configuration using SNMP.

Section 5 details the applicability of this MIB set to the EP

Section 5 details the applicability of this MIB set to the EP

configuration.

configuration.

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

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

of PANA.

of PANA.

Section 7 defines some additional PANA-specific objects that extend

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

the IPSec SPD-MIB module [I-D.ietf-ipsp-spd-mib] in order to entirely

satisfy the PAA-EP interface requirements.

satisfy the PAA-EP interface requirements.

Finally, Section 9 addresses the security considerations.

Finally, Section 8 addresses the security considerations.

3. The Internet-Standard Management Framework

3. The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current

For a detailed overview of the documents that describe the current

Internet-Standard Management Framework, please refer to section 7 of

Internet-Standard Management Framework, please refer to section 7 of

[RFC3410].

[RFC3410].

Managed objects are accessed via a virtual information store, termed

Managed objects are accessed via a virtual information store, termed

the Management Information Base or MIB. MIB objects are generally

the Management Information Base or MIB. MIB objects are generally

accessed through the Simple Network Management Protocol (SNMP).

accessed through the Simple Network Management Protocol (SNMP).

skipping to change at page 12, line 12

skipping to change at page 13, line 12

terminate PANA sessions for PaCs that are authorized for access

terminate PANA sessions for PaCs that are authorized for access

through the EP.

through the EP.

5. Applicability of IPSec configuration MIBs

5. Applicability of IPSec configuration MIBs

This section details the applicability of existing IPSec

This section details the applicability of existing IPSec

configuration MIB modules to the EP configuration. These were found

configuration MIB modules to the EP configuration. These were found

to have general applicability and a fair level of re-usability for

to have general applicability and a fair level of re-usability for

the PANA EP configuration:

the PANA EP configuration:

IPSec Security Policy Database (SPD) MIB:

IPSec Security Policy Database (SPD) Configuration MIB:

[I-D.ietf-ipsp-spd-mib] defines a MIB module for configuration of

[I-D.ietf-ipsp-spd-mib] defines a MIB module (IPSEC-SPD-MIB)for

an IPSec Security Policy Database (SPD). No IPSec or IKE specific

configuration of an IPSec Security Policy Database (SPD). No

actions are defined within this document.

IPSec or IKE specific actions are defined within this document.

IPSec IKE Action MIB:

IPSec Security Policy IKE Action MIB:

[I-D.ietf-ipsp-ikeaction-mib] defines a MIB module for

[I-D.ietf-ipsp-ikeaction-mib] defines a MIB module

configuration of an IKE action within the IPSec SPD.

(IPSEC-IKEACTION-MIB) for configuration of an IKE action within

the IPSec SPD.

IPSec Security Policy IPSec Action MIB:

[I-D.ietf-ipsp-ipsecaction-mib] defines a MIB module

(IPSEC-IPSECACTION-MIB) for configuring IPsec actions within the

IPSec SPD.

The IPSec Configuration MIBs set does not define MIB modules for

The IPSec Configuration MIBs set does not define MIB modules for

monitoring the state of an IPSec device. Neither it does define MIB

monitoring the state of an IPSec device. Neither it does define MIB

modules for configuring other policy related actions. The purpose of

modules for configuring other policy related actions. The purpose of

these MIBs is to allow administrators to be able to configure policy

these MIBs is to allow administrators to be able to configure policy

with respect to the IPSec [RFC2401]/IKE [RFC2409] protocols.

with respect to the IPSec [RFC2401]/IKE [RFC2409] protocols.

5.1 General Access Control

5.1 General Access Control

The EP enforces binary authorization by filtering data traffic on the

The EP enforces binary authorization by filtering data traffic on the

skipping to change at page 13, line 34

skipping to change at page 14, line 41

* IPv6 Flow Label Match (Ipv6 only)

* IPv6 Flow Label Match (Ipv6 only)

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

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

of the entire filter.

of the entire filter.

-- L2 address-based filter:

-- L2 address-based filter:

[I-D.ietf-pana-pana] says the Device-Id AVP (code 1025) is of

[I-D.ietf-pana-pana] says the Device-Id AVP (code 1025) is of

Address Type [RFC3588]. The content for link-layer addresses is

Address Type [RFC3588]. The content for link-layer addresses is

expected to be specified in specific documents that describe how

expected to be specified in specific documents that describe how

IP operates over different link-layers. For instance, [RFC2464].

IP operates over different link-layers. For instance, IPv6 over

Ethernet is described in [RFC2464].

To this end, additional filters are designed in the present

To this end, additional filters are designed in the present

document. Section 7 defines a link-layer filter table, which test

document. Section 7 defines a link-layer filter table, which test

the L2 address (e.g. MAC address, port, DSL line) of a given

the L2 address (e.g. MAC address, port, DSL line) of a given

packet.

packet.

Do note that the definition of this table does not assume the

Do note that the definition of this table does not assume the

usage of any particular Link layer.

usage of any particular Link layer.

-- Static Actions:

-- Static Actions:

The actions encapsulated within the SPD-MIB module are basic

The actions encapsulated within the SPD-MIB module are basic

skipping to change at page 16, line 5

skipping to change at page 17, line 7

the spdIPInterfaceType and spdIPInterfaceAddress objects are included

the spdIPInterfaceType and spdIPInterfaceAddress objects are included

to indicate which interface the action was executed in association

to indicate which interface the action was executed in association

with and if the packet was inbound or outbound through the endpoint.

with and if the packet was inbound or outbound through the endpoint.

See [I-D.ietf-ipsp-spd-mib] for further details.

See [I-D.ietf-ipsp-spd-mib] for further details.

If the traffic detected is Link-layer traffic, the objects sent must

If the traffic detected is Link-layer traffic, the objects sent must

include the index of the interface which detected such traffic and

include the index of the interface which detected such traffic and

potentially the L2 address source of the traffic. See Section 7 for

potentially the L2 address source of the traffic. See Section 7 for

further details.

further details.

If reliability needs to be guaranteed for the notifications

(panaNewPacIPNotification and panaNewPacL2Notification), hence inform

notification, which is acknowledged, MUST be used. Then the PAA

needs to have engine-id to be the authoritative of SNMP clock between

EP and PAA (for inform operation the responder becomes the

authoritative).

6. EP Configuration Example

6. EP Configuration Example

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

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

6.1 General IP-based Access Control

6.1 Common setup

Below is a usage example of the IPSec modules. In this example, we

need to configure the SPD so that EP accepts IP packets coming

from/going to the PaC.

The "EndPoint to Group" table is used to map policy (groupings) onto

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.

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

Any policy group assigned to an endpoint is then used to control

access to the traffic passing by it.

access to the traffic passing by it.

So far, we define below two policy groups at the EP interface

So far, we define below two policy groups at the EP interface

("EP-SPD-IN" and "EP-SPD-OUT").

("EP-SPD-IN" and "EP-SPD-OUT").

spdEndpointToGroupTable.1 =

spdEndpointToGroupTable, row 1:

spdEndGroupDirection = incoming;

spdEndGroupDirection = incoming;

spdEndGroupIdentType = IPv4;

spdEndGroupIdentType = IPv4;

spdEndGroupAddress = EP-ADDR;

spdEndGroupAddress = EP-ADDR;

spdEndGroupName = "EP-SPD-IN";

spdEndGroupName = "EP-SPD-IN";

spdEndpointToGroupTable.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 packets coming from/going to "PaC1" and

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

the EP we are provisioning.

allowed prior to any configuration. The following configuration

illustrates the incoming allowed unprotected traffic:

spdGroupContentsTable.2 =

spdGroupContentsTable, row 1:

spdGroupContName = "EP-SPD-IN";

spdGroupContName = "EP-SPD-IN";

spdGroupContPriority = 1;

spdGroupContPriority = '10';

spdGroupContFilter = spdIpHeaderFilterTable.1;

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 Neighbor

Discovery, DHCP, etc). The following configuration illustrates the

case of incoming DHCP traffic:

spdGroupContentsTable, row 2:

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

spdGroupContPriority = '1';

spdGroupContFilter = spdIpHeaderFilterTable.10;

spdGroupContComponentType = rule;

spdGroupContComponentType = rule;

spdGroupContComponentName = "EP-PaC1-IN";

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

spdGroupContentsTable.2 =

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

spdGroupContName = "EP-SPD-OUT";

which matches the DHCP packets:

spdGroupContPriority = 1;

spdGroupContFilter = spdIpHeaderFilterTable.2;

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'. In the whole

section, 'PaC1-IP@' is the IP address of '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 3:

spdGroupContName = "EP-SPD-IN";

spdGroupContPriority = '100';

spdGroupContFilter = spdIpHeaderFilterTable.1;

spdGroupContComponentType = rule;

spdGroupContComponentType = rule;

spdGroupContComponentName = "EP-PaC1-OUT";

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

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

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

PaC.

IP packets coming from the PaC:

spdIpHeaderFilterTable, row 1:

spdIpHeaderFilterTable.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.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 "Rule Defininition" table links a rule with a given action in the

The following entries links the two filters defined above with the

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

"accept" action.

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

MIB (spdStaticActions.3).

spdRuleDefinitionTable.1 =

spdRuleDefinitionTable, row 2:

spdRuleDefName = "PaC1-ACCEPT-IN";

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

spdRuleDefDescription = "Allow Incoming IP packets from PaC1";

spdRuleDefDescription = "Allow Incoming IP packets from PaC1";

spdRuleDefFilter = spdIpHeaderFilterTable.1;

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilterNegated = false (default);

spdRuleDefFilterNegated = false (default);

spdRuleDefAction = spdStaticActions.3;

spdRuleDefAction = spdAcceptAction;

spdRuleDefinitionTable.2 =

spdRuleDefinitionTable, row 3:

spdRuleDefName = "PaC1-ACCEPT-OUT";

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

spdRuleDefDescription = "Allow Outgoing IP packets to PaC1";

spdRuleDefDescription = "Allow Outgoing IP packets to PaC1";

spdRuleDefFilter = spdIpHeaderFilterTable.2;

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilterNegated = false (default);

spdRuleDefFilterNegated = false (default);

spdRuleDefAction = spdStaticActions.3;

spdRuleDefAction = spdAcceptAction;

This means that any packet coming from/going to the PaC is now

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

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.2 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 and IPSECACTION-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 4:

spdGroupContentsTable.1 =

spdGroupContName = "EP-SPD-IN";

spdGroupContName = "EP-SPD-IN";

spdGroupContPriority = 1;

spdGroupContPriority = '1';

spdGroupContFilter = ipiaStaticFilters.1;

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

spdGroupContentsTable, row 5:

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

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.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 = spdIpHeaderFilterTable.1;

spdRuleDefFilter = spdTrueFilterInstance;

spdRuleDefFilterNegated = false (default);

spdRuleDefFilterNegated = false (default);

spdRuleDefAction = spdIkeActionTable.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.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";

ipiaSaNegotiationParametersTable.1 =

ipiaSaNegParamName = "SA-PaC1";

ipiaSaNegParamMinLifetimeSecs = xxx;

ipiaSaNegParamMinLifetimeKB = xxx;

ipiaSaNegParamRefreshThreshSecs = xxx;

ipiaSaNegParamRefreshThresholdKB = xxx;

ipiaSaNegParamIdleDurationSecs = xxx;

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

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

the idKeyId to use in IKE messages with PaC1:

corresponding credentials table entry:

ipiaPeerIdentityFilterTable.1 =

ipiaPeerIdFiltName = "PaC1";

ipiaPeerIdFiltIdentityType = id_key_id;

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

The following entry links a given identity (PaC1) with an entry in

the "Credentials" table.

ipiaIkeIdentityTable.1 =

ipiaIkeIdentityTable, row 1:

spdEndGroupIdentType = IPv4;

spdEndGroupIdentType = IPv4;

spdEndGroupAddress = EP-ADDR;

spdEndGroupAddress = 'EP-ADDR';

ipiaIkeActIdentityType = id_key_id;

ipiaIkeActIdentityType = id_Key_Id;

ipiaIkeActIdentityContext = PANA;

ipiaIkeActIdentityContext = 'PANA';

ipiaIkeIdCredentialName = "PaC1-PSK";

ipiaIkeIdCredentialName = "PaC1-PSK";

Finally the pre-shared key derivated at the PAA is set here:

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

Credentials table (IPSECACTION-MIB):

ipiaCredentialFilterTable.1 =

ipsaCredentialTable, row 1:

ipiaCredFiltName = "PaC1-PSK";

ipsaCredName = "PaC1-PSK";

ipiaCredFiltCredentialType = sharedSecret;

ipsaCredType = sharedSecret;

ipiaCredFiltMatchFieldName = none;

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

ipiaCredFiltMatchFieldValue = "PSK-from-PAA";

ipsaCredSize = 'xxx';

ipsaMgnName = "xxx";

ipsaRemoteID = 'PaC1';

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

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:

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.

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 30, line 5

skipping to change at page 34, line 5

}

}

MODULE IPSEC-SPD-MIB

MODULE IPSEC-SPD-MIB

MANDATORY-GROUPS { spdActionLoggingObjectGroup }

MANDATORY-GROUPS { spdActionLoggingObjectGroup }

::= { panaCompliances 2 }

::= { panaCompliances 2 }

END

END

8. Open Issues

8. Security Considerations

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.

9. Security Considerations

The MIB defined in the present document relates to a system which

The MIB defined in the present document relates to a system which

will provide network access. As such, improper manipulation of the

will provide network access. As such, improper manipulation of the

objects represented by this MIB may result in denial of service to a

objects represented by this MIB may result in denial of service to a

large number of end-users. In addition, manipulation of the

large number of end-users. In addition, manipulation of the

panaL2FilterTable and spdIpHeaderFilterTable may allow an end-user to

panaL2FilterTable and spdIpHeaderFilterTable may allow an end-user to

gain network access, spoof their IP addresses, change the authorized

gain network access, spoof their IP addresses, change the authorized

device identifiers, or affect other end-users in either a positive or

device identifiers, or affect other end-users in either a positive or

negative manner.

negative manner.

skipping to change at page 31, line 31

skipping to change at page 34, line 31

network operations. These are the tables and objects and their

network operations. These are the tables and objects and their

sensitivity/vulnerability:

sensitivity/vulnerability:

o The use of panaIPL2FilterTable to specify which Link-layer

o The use of panaIPL2FilterTable to specify which Link-layer

addresses are authorized to access the network is considered to be

addresses are authorized to access the network is considered to be

only limited protection and does not protect against attacks which

only limited protection and does not protect against attacks which

spoof the management station's IP address. The use of SNMPv3

spoof the management station's IP address. The use of SNMPv3

security is mandated. Specifically, SNMPv3 VACM and USM MUST be

security is mandated. Specifically, SNMPv3 VACM and USM MUST be

used with any v3 agent which implements this MIB.

used with any v3 agent which implements this MIB.

As described in Section 2.1, it is assumed that PAA and EP are

pre-configured to be able to communicate each other with a required

security association. The pre-configured SNMP user passphrase for

the security association between PAA and EP should not be used for a

long term and should be updated at a reasonable frequency.

It might be sufficient to use the same SNMP user identity and

passphrase for all EPs controlled by the same PAA (the same thing can

apply even when the EPs are controlled by multiple PAAs.) Note that

even if the same SNMP user identity and passphrase for all EPs are

used, the different SNMP authentication and encryption keys are

derived for each EP, because the combination of SNMP user identity

and engine-id is used for deriving the keys.

SNMP versions prior to SNMPv3 did not include adequate security.

SNMP versions prior to SNMPv3 did not include adequate security.

Even if the network itself is secure (for example by using IPSec),

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

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

allowed to access and GET/SET (read/change/create/delete) the objects

in this MIB module.

in this MIB module.

It is RECOMMENDED that implementers consider the security features as

It is RECOMMENDED that implementers consider the security features as

provided by the SNMPv3 framework (see [RFC3410], section 8),

provided by the SNMPv3 framework (see [RFC3410], section 8),

including full support for the SNMPv3 cryptographic mechanisms (for

including full support for the SNMPv3 cryptographic mechanisms (for

authentication and privacy).

authentication and privacy).

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

9. Acknowledgements

This document originaly leverages on similar works done in the MIDCOM

The authors would like to thank David Perkins for the MIB deep

working group. Thanks to the authors of those IDs.

inspection and Robert Story, who provided very helpful

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

10. References

11.1 Normative References

10.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)", Internet-Draft draft-ietf-pana-pana-07,

progress), October 2004.

December 2004.

[I-D.ietf-pana-requirements]

[I-D.ietf-pana-requirements]

Yegin, A. and Y. Ohba, "Protocol for Carrying

Yegin, A. and Y. Ohba, "Protocol for Carrying

Authentication for Network Access (PANA)Requirements",

Authentication for Network Access (PANA)Requirements",

draft-ietf-pana-requirements-09 (work in progress), August

Internet-Draft draft-ietf-pana-requirements-09, August

2004.

2004.

[I-D.ietf-pana-ipsec]

[I-D.ietf-pana-ipsec]

Parthasarathy, M., "PANA enabling IPsec based Access

Parthasarathy, M., "PANA enabling IPsec based Access

Control", draft-ietf-pana-ipsec-04 (work in progress),

Control", Internet-Draft draft-ietf-pana-ipsec-05,

September 2004.

December 2004.

[I-D.ietf-pana-threats-eval]

[I-D.ietf-pana-threats-eval]

Parthasarathy, M., "Protocol for Carrying Authentication

Parthasarathy, M., "Protocol for Carrying Authentication

and Network Access Threat Analysis and Security

and Network Access Threat Analysis and Security

Requirements", draft-ietf-pana-threats-eval-07 (work in

Requirements",

progress), August 2004.

Internet-Draft draft-ietf-pana-threats-eval-07, August

2004.

[I-D.ietf-pana-framework]

[I-D.ietf-pana-framework]

Jayaraman, P., "PANA Framework",

Jayaraman, P., "PANA Framework",

draft-ietf-pana-framework-02 (work in progress), September

Internet-Draft draft-ietf-pana-framework-03, December

2004.

2004.

[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model

[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model

(USM) for version 3 of the Simple Network Management

(USM) for version 3 of the Simple Network Management

Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

[I-D.ietf-ipsp-spd-mib]

[I-D.ietf-ipsp-spd-mib]

Hardaker, W., "IPsec Security Policy Database

Hardaker, W., "IPsec Security Policy Database

Configuration MIB", draft-ietf-ipsp-spd-mib-01 (work in

Configuration MIB",

progress), October 2004.

Internet-Draft draft-ietf-ipsp-spd-mib-01, October 2004.

[I-D.ietf-ipsp-ikeaction-mib]

[I-D.ietf-ipsp-ikeaction-mib]

Hardaker, W., "IPsec Security Policy IKE Action MIB",

Hardaker, W., "IPsec Security Policy IKE Action MIB",

draft-ietf-ipsp-ikeaction-mib-01 (work in progress),

Internet-Draft draft-ietf-ipsp-ikeaction-mib-01, October

October 2004.

2004.

[I-D.ietf-ipsp-ipsecaction-mib]

Hardaker, W., "IPsec Security Policy IPsec Action MIB",

Internet-Draft draft-ietf-ipsp-ipsecaction-mib-01, October

2004.

[I-D.ietf-aaa-diameter-cc]

[I-D.ietf-aaa-diameter-cc]

Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H.

Mattila, L., Koskinen, J., Stura, M., Loughney, J. and H.

Hakala, "Diameter Credit-control Application",

Hakala, "Diameter Credit-control Application",

draft-ietf-aaa-diameter-cc-06 (work in progress), August

Internet-Draft draft-ietf-aaa-diameter-cc-06, August 2004.

2004.

[I-D.ietf-aaa-eap]

[I-D.ietf-aaa-eap]

Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible

Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible

Authentication Protocol (EAP) Application",

Authentication Protocol (EAP) Application",

draft-ietf-aaa-eap-09 (work in progress), August 2004.

Internet-Draft draft-ietf-aaa-eap-10, November 2004.

[I-D.ietf-eap-keying]

[I-D.ietf-eap-keying]

Aboba, B., "Extensible Authentication Protocol (EAP) Key

Aboba, B., "Extensible Authentication Protocol (EAP) Key

Management Framework", draft-ietf-eap-keying-03 (work in

Management Framework",

progress), July 2004.

Internet-Draft draft-ietf-eap-keying-04, November 2004.

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the

Internet Protocol", RFC 2401, November 1998.

Internet Protocol", RFC 2401, November 1998.

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange

(IKE)", RFC 2409, November 1998.

(IKE)", RFC 2409, November 1998.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision

3", BCP 9, RFC 2026, October 1996.

3", BCP 9, RFC 2026, October 1996.

skipping to change at page 34, line 43

skipping to change at page 38, line 47

[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An

[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An

Architecture for Describing Simple Network Management

Architecture for Describing Simple Network Management

Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,

Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,

December 2002.

December 2002.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,

[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,

McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of

McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of

Management Information Version 2 (SMIv2)", STD 58, RFC

Management Information Version 2 (SMIv2)", STD 58,

2578, April 1999.

RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,

[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,

McCloghrie, K., Rose, M. and S. Waldbusser, "Textual

McCloghrie, K., Rose, M. and S. Waldbusser, "Textual

Conventions for SMIv2", STD 58, RFC 2579, April 1999.

Conventions for SMIv2", STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,

[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,

"Conformance Statements for SMIv2", STD 58, RFC 2580,

"Conformance Statements for SMIv2", STD 58, RFC 2580,

April 1999.

April 1999.

[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet

[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet

Networks", RFC 2464, December 1998.

Networks", RFC 2464, December 1998.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.

Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[802.11i] IEEE P802, "Wireless MAC and PHY specifications, MAC

[802.11i] IEEE P802, "Wireless MAC and PHY specifications, MAC

security enhancements", IEEE 802.11i, July 2004.

security enhancements", IEEE 802.11i, July 2004.

11.2 Informative References

10.2 Informative References

[I-D.yacine-pana-paa2ep-prot-eval]

[I-D.yacine-pana-paa2ep-prot-eval]

Mghazli, Y., "PANA PAA-EP protocol considerations",

Mghazli, Y., "PANA PAA-EP protocol considerations",

draft-yacine-pana-paa2ep-prot-eval-00 (work in progress),

Internet-Draft draft-yacine-pana-paa2ep-prot-eval-00,

October 2003.

October 2003.

[I-D.yacine-pana-paa-ep-reqs]

[I-D.yacine-pana-paa-ep-reqs]

Mghazli, Y., "PANA PAA-EP Protocol Requirements",

Mghazli, Y., "PANA PAA-EP Protocol Requirements",

draft-yacine-pana-paa-ep-reqs-00 (work in progress),

Internet-Draft draft-yacine-pana-paa-ep-reqs-00, October

October 2003.

2003.

Authors' Addresses

Authors' Addresses

Yacine El Mghazli (Editor)

Yacine El Mghazli (Editor)

Alcatel

Alcatel

Route de Nozay

Route de Nozay

Marcoussis 91460

Marcoussis 91460

France

France

EMail: [email-masked]

Email: [email-masked]

Yoshihiro Ohba

Yoshihiro Ohba

Toshiba America Research, Inc.

Toshiba America Research, Inc.

1, Telcordia Drive

1, Telcordia Drive

Piscataway, NJ 08854

Piscataway, NJ 08854

USA

USA

EMail: [email-masked]

Email: [email-masked]

Julien Bournelle

Julien Bournelle

GET/INT

GET/INT

9, rue Charles Fourier

9, rue Charles Fourier

Evry 91011

Evry 91011

France

France

EMail: [email-masked]

Email: [email-masked]

Intellectual Property Statement

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any

The IETF takes no position regarding the validity or scope of any

Intellectual Property Rights or other rights that might be claimed to

Intellectual Property Rights or other rights that might be claimed to

pertain to the implementation or use of the technology described in

pertain to the implementation or use of the technology described in

this document or the extent to which any license under such rights

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

might or might not be available; nor does it represent that it has

made any independent effort to identify any such rights. Information

made any independent effort to identify any such rights. Information

on the procedures with respect to rights in RFC documents can be

on the procedures with respect to rights in RFC documents can be

skipping to change at page 37, line 41

skipping to change at page 41, line 41

This document and the information contained herein are provided on an

This document and the information contained herein are provided on an

"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET

OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET

ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE

INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

Copyright Statement

Copyright (C) The Internet Society (2004). This document is subject

Copyright (C) The Internet Society (2005). This document is subject

to the rights, licenses and restrictions contained in BCP 78, and

to the rights, licenses and restrictions contained in BCP 78, and

except as set forth therein, the authors retain all their rights.

except as set forth therein, the authors retain all their rights.

Acknowledgment

Acknowledgment

Funding for the RFC Editor function is currently provided by the

Funding for the RFC Editor function is currently provided by the

Internet Society.

Internet Society.

End of changes.

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

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