PANA Framework Prakash Jayaraman, Rafa Marin Lopez, Yoshihiro Ohba, Mohan Parthasarathy, Alper Yegin IETF 59

2 Framework Functional model Signaling flow Deployment environments IP address configuration Data traffic protection Provisioning Network selection Authentication method choice DSL deployment WLAN deployment

IETF 59 3 Functional Model RADIUS/ Diameter/ PANA LDAP/ API | PaC | | PAA | | AS | ^ ^ | | | | IKE/ >| EP |< SNMP/ API 4-way handshake

IETF 59 4 Signaling Flow PaC EP PAA AS | PANA | | AAA | | | | | | | | | | SNMP | | | | | | | Sec.Assoc. | | | | | | | | Data traffic | | | | | | | | | |

IETF 59 5 Deployment Environments (a) Networks where a secure channel is already available prior to running PANA –(a.1) Physical security. E.g.: DSL –(a.2) Cryptographic security. E.g.: cdma2000 (b) Networks where a secure channel is created after running PANA –(b.1) Link-layer per-packet security. E.g.: Using WPA- PSK. –(b.2) Network-layer per-packet security. E.g.: Using IPsec.

IETF 59 6 IP Address Configuration Pre-PANA address: PRPA –Configured before PANA Post-PANA address: POPA –Configured after PANA when: IPsec is used, or PRPA is link-local or temporary –PAA informs PaC if POPA needed

IETF 59 7 PRPA Configuration Possible ways: –Static –DHCPv4 (global, or private address) –IPv4 link-local –DHCPv6 –IPv6 address autoconfiguration (global, or link- local)

IETF 59 8 POPA Configuration (no IPsec) DHCPv4/v6 IPv4: –POPA replaces PRPA (prevent address selection problem) –Host route between PaC and PAA (preserve on- link communication) IPv6: –use both PRPA and POPA at the same time

IETF 59 9 POPA Configuration (IPsec) Possible ways: –IKEv2 configuration –DHCP configuration of IPsec tunnel mode (RFC 3456) PRPA used as tunnel outer address, POPA as tunnel inner address

IETF Combinations PRPAPOPA L1-L2 per-packet security (no IPsec) Static IPv4 (DHCP) IPv6 global (DHCP, stateless) none IPv4 link-local IPv4 temporary (DHCP) IPv4 (DHCP) IPv6 link-localIPv6 global (DHCP, stateless) L3 per-packet security (IPsec) Static IPv6 global (DHCP, stateless) IPv4 (DHCP) IPv6 link-local IPv4 link-local IKEv2 RFC3456 TOA TIA

IETF Additional Approaches: (1) Using a PRPA as TIA IPv6: –Configure a link-local and global before PANA (DHCPv6 or stateless) –TIA=global, TOA=link-local Requires SPD selection based on the name (session-ID), not the IP address Explicit support in RFC2401bis –Name is set, address selectors are NULL RFC2401? Not clear. –Racoon’s generate_policy directive Authenticate peer by PSK, accept proposed TIA (skip SPD check), than create SPD Should we include this?

IETF Additional Approaches: (2) Using a PRPA as TIA IPv4: –Configure a global address before PANA (static, or DHCPv4) –TIA=TOA=PRPA RFC2401: Same considerations. Forwarding considerations: –Requires special handling on EP, or else: tunnel_to PRPA(tunnel to PRPA(tunnel to PRPA(to PRPA)))... –FreeSwan handles this. Others? Should we include this?

IETF Data Traffic Protection Already available in type (a) environments Enabled by PANA in type (b) environments –EAP generated keys –Secure association protocol draft-ietf-pana-ipsec-02

IETF PAA-EP Provisioning Protocol EP is the closest IP-capable access device to PaCs Co-located with PAA or separate –draft-yacine-pana-snmp-01 –Carries IP or L2 address, optionally cryptographic keys One or more EPs per PAA EP may detect presence of PaC and trigger PANA by notifying PAA

IETF Network (ISP) Discovery and Selection Traditional selection: –NAI-based –Port number or L2 address based PANA-based discovery and selection: –PAA advertises ISPs –PaC explicitly picks one

IETF Authentication Method Choice Depends on the environment

IETF DSL Host ISP1 | DSL link | CPE NAS ISP2 | (Bridge/NAPT/Router) | Host ISP3 premise PANA needed when static IP or DHCP- based configuration is used (instead of PPP*)

IETF DSL Deployments Bridging mode: Host--+ (PaC) | CPE NAS ISP | (Bridge) (PAA,EP,AR) Host--+ (PaC) Address Translation (NAPT) Mode: Host--+ | CPE NAS ISP | (NAPT, PaC) (PAA,EP,AR Host--+

IETF DSL Deployment Router mode: Host--+ | CPE NAS ISP | (Router,PaC) (PAA,EP,AR) Host--+

IETF Dynamic ISP Selection As part of DHCP protocol or an attribute of DSL access line –DHCP client id –Run DHCP, and PANA –PRPA is the ultimate IP address (no POPA) As part of PANA authentication –Temporary PRPA via zeroconf or DHCP with NAP –Run PANA for AAA –POPA via DHCP, replace PRPA

IETF WLAN Network-layer per-packet security (IPsec): –EP and PAA on access router Link-layer per-packet security (WPA-PSK): –EP is on access point, PAA is on access router

IETF IPsec, IKEv2 PaC AP DHCPv4 Server PAA EP(AR) | Link-layer | | | | | association| | | | | | | | | | DHCPv4 | | | | | | | | | | | | |PANA(Discovery and initial handshake phase | | & PAR-PAN exchange in authentication phase) | | | | | | | | | | |Authorization| | | |[IKE-PSK, | | | | PaC-DI, | | | | Session-Id] | | | | >| | | | | |PANA(PBR-PBA exchange in authentication phase) | | | | | | | | | | IKE | | | (with Configuration Payload exchange or equivalent) | | | | | | | IPv4: –IPsec-TOA=PRPA (dhcp) –IPsec-TIA=POPA (IKE) Alternative: RFC 3456 IPv6: –IPsec-TOA= PRPA (link-local) –IPsec-TIA= POPA (IKE)

IETF Bootstrapping WPA/IEEE i Pre-shared key mode (PSK) enabled MAC address is used as DI EP is on access point Provides: –Centralized AAA –Protected disconnection No changes to WPA or IEEE i required

IETF Flow… | Physical AP | | | | |Virtual AP1 | | Unauth | |(open-access) |---- VLAN\ | | | | \ | | |PAA/AR/| |PaC| ~~~~ | | |DHCP | | | |Server | | |Virtual AP2 | | / | |(WPA PSK mode)|---- Auth / | | | | | VLAN | | | | | | | Internet 1- Associate with unauthenticated VLAN AP 2- Configure PRPA via DHCP or link-local 3- Perform PANA and generate PMK 4- Associate with authenticated VLAN AP, perform 4-way handshake, generate PTK 5- Obtain new IP address

IETF Co-located PAA and AP(EP) Does not require virtual AP switching PANA, DHCP, ARP, ND traffic allowed on the 802.1X uncontrolled port

IETF Capability Discovery Types of networks: –IEEE 802.1X-secured Look at RSN information element in beacon frames –PANA-secured Data driven PANA discovery Client initiated discovery –Unauthenticated (free)

The End

Should this I-D become a PANA WG item?

IETF IPsec, DHCP PaC AP DHCPv4 Server PAA EP(AR) | Link-layer | | | | | association| | | | | | | | | | DHCPv4 | | | | | | | | | | | | |PANA(Discovery and Initial Handshake phase | | & PAR-PAN exchange in Authentication phase) | | | | | | | | | | | | |Authorization| | | | |[IKE-PSK, | | | | | PaC-DI, | | | | | Session-Id] | | | | | >| | | | | | |PANA(PBR-PBA exchange in Authentication phase) | | | | | | | | | | | IKE | | | | | | | | | IPv4: –IPsec-TIA= IPsec-TOA= PRPA (dhcp) IPv6: –IPsec-TOA= PRPA (link-local) –IPsec-TIA= POPA (dhcp) IPv6 can also use stateless address autoconf.