29
PANA Framework <draft-ohba-pana- framework-00.txt> Prakash Jayaraman, Rafa Marin Lopez, Yoshihiro Ohba, Mohan Parthasarathy, Alper Yegin IETF 59

PANA Framework

  • Upload
    ketan

  • View
    88

  • Download
    0

Embed Size (px)

DESCRIPTION

PANA Framework. Prakash Jayaraman, Rafa Marin Lopez, Yoshihiro Ohba, Mohan Parthasarathy, Alper Yegin IETF 59. Framework. Functional model Signaling flow Deployment environments IP address configuration Data traffic protection Provisioning - PowerPoint PPT Presentation

Citation preview

Page 1: PANA Framework

PANA Framework

<draft-ohba-pana-framework-00.txt>

Prakash Jayaraman, Rafa Marin Lopez, Yoshihiro Ohba, Mohan Parthasarathy, Alper Yegin

IETF 59

Page 2: PANA Framework

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

Page 3: PANA Framework

IETF 59 3

Functional Model

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

Page 4: PANA Framework

IETF 59 4

Signaling Flow

PaC EP PAA AS | PANA | | AAA | |<---------------------------->|<------------->| | | | | | | SNMP | | | |<------------>| | | Sec.Assoc. | | | |<------------->| | | | | | | | Data traffic | | | |<-----------------> | | | | | |

Page 5: PANA Framework

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.

Page 6: PANA Framework

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

Page 7: PANA Framework

IETF 59 7

PRPA Configuration

• Possible ways:– Static– DHCPv4 (global, or private address)– IPv4 link-local– DHCPv6– IPv6 address autoconfiguration (global, or link-

local)

Page 8: PANA Framework

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

Page 9: PANA Framework

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

Page 10: PANA Framework

IETF 59 10

Combinations

PRPA POPA

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

Page 11: PANA Framework

IETF 59 11

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?

Page 12: PANA Framework

IETF 59 12

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?

Page 13: PANA Framework

IETF 59 13

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

Page 14: PANA Framework

IETF 59 14

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

Page 15: PANA Framework

IETF 59 15

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

Page 16: PANA Framework

IETF 59 16

Authentication Method Choice

• Depends on the environment

Page 17: PANA Framework

IETF 59 17

DSL

Host--+ +-------- ISP1 | DSL link | +----- CPE ---------------- NAS ----+-------- ISP2 | (Bridge/NAPT/Router) | Host--+ +-------- ISP3

<------- customer --> <------- NAP -----> <---- ISP ---> premise

• PANA needed when static IP or DHCP-based configuration is used (instead of PPP*)

Page 18: PANA Framework

IETF 59 18

DSL DeploymentsBridging 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--+

Page 19: PANA Framework

IETF 59 19

DSL Deployment

Router mode:

Host--+ |

+----- CPE ---------------- NAS ------------- ISP

| (Router,PaC) (PAA,EP,AR)

Host--+

Page 20: PANA Framework

IETF 59 20

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

Page 21: PANA Framework

IETF 59 21

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

Page 22: PANA Framework

IETF 59 22

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)

Page 23: PANA Framework

IETF 59 23

Bootstrapping WPA/IEEE 802.11i

• 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 802.11i required

Page 24: PANA Framework

IETF 59 24

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

Page 25: PANA Framework

IETF 59 25

Co-located PAA and AP(EP)

• Does not require virtual AP switching

• PANA, DHCP, ARP, ND traffic allowed on the 802.1X uncontrolled port

Page 26: PANA Framework

IETF 59 26

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)

Page 27: PANA Framework

The End

Page 28: PANA Framework

Should this I-D become a PANA WG item?

Page 29: PANA Framework

IETF 59 29

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.