7/14/2003 IETF57

PANA enabling IPsec based Access control

draft-mohanp-pana-ipsec-00.txt

Mohan Parthasarathy

Tahoe Networks

- Presented by Hannes Tschofenig

7/14/2003 IETF57

Enabling IPsec Access control

• PANA protocol - used to authenticate the client.• PANA protocol - also capable of sending

Protection-capability-AVP (with PANA-Bind-Request) asking (enforcing) the client to use L2 or L3 cipher.

• But PANA protocol does not specify the details on how the L2/L3 SAs are established etc.

• This draft essentially discusses the details of using IPsec as the L3 cipher.

7/14/2003 IETF57

Pre-requisites for using IPsec

• PANA client (PaC) should learn the IP address of the enforcement point (EP) during the PANA exchange.

• PaC learns that the network uses IPsec for securing the PaC-EP link.

• PaC has already acquired an IP address and PAA knows about the IP address of the PaC before the exchange starts.

7/14/2003 IETF57

IKE/IPsec details

• At the end of a successful authentication, a PANA SA is established between PaC and PAA (assuming the underlying EAP method is capable of generating a Master Key (MK)).

• IKE pre-shared key is derived from the PANA SA (TBD).

• EP securely receives the following from PAA: - IKE pre-shared key

- IP address of PaC - PANA session id

7/14/2003 IETF57

IKE/IPsec details (contd..)

• Manual keying not supported. IKE is used to establish IPsec SAs.

• Both Aggressive mode and Main mode is easy to support.

• In main mode, PaC and EP uses the IP address as the client identifier.

• In Aggressive mode, PaC and EP use the PANA session id as identifier - part of ID_KEY_ID payload.

7/14/2003 IETF57

IKE/IPsec details (contd..)

• After Phase I SA is established, quick mode exchange is performed to setup an IPsec SA.

• Quick mode IPsec SA is an ESP transport mode SA used in conjunction with IP-IP tunnel interface (IP-IP transport mode SA).

• IPsec tunnel mode SA also can be used.

7/14/2003 IETF57

IPv4/IPv6 Details

• Draft has specific examples on SPD entries, IPsec processing details for both IPv4 and IPv6.

• In IPv4, the SPD entries are very simple. All of the traffic is tunneled to the security gateway (EP).

• In IPv6, there are a few exceptions.• EP is the security gateway – a router. Implies hop

count is decremented by 1.• This won’t work for RD/ND messages which

assume nhop count = 255.

7/14/2003 IETF57

IPv4/IPv6 details (contd..)

• As IPsec selectors are not capable of expressing bypass rules for ND/RD messages:

- Use just fe80::/10 as the on-link prefix i.e., all other packets are sent to the default router. - Bypass IPsec for packets destined to fe80::/10.• All packets are tunneled to the link-local address

of the EP.

7/14/2003 IETF57

Double IPsec

• If the PaC uses IPsec for secure remote access, there will be separate SPD entries for protecting the remote network traffic.

• Packets will be protected twice. Once for the remote network and once for the local network.

• This case of iterated tunneling is discussed in RFC2401 (IPsec).

7/14/2003 IETF57

Open Issues

• IKE pre-shared key derivation from PANA SA.

• Use IPsec tunnel mode to describe the IPsec details instead of IP-IP transport mode.

7/14/2003 IETF57

Question to WG

• Should we make this a WG I-D?