PANA Issues and Resolutions

Slides:



Advertisements
Similar presentations
© 2006 Cisco Systems, Inc. All rights reserved.IP6FD v2.0—2-1 IPv6 Operations Defining and Configuring Neighbor Discovery.
Advertisements

1 Internet Protocol Version 6 (IPv6) What the caterpillar calls the end of the world, nature calls a butterfly. - Anonymous.
Network Layer IPv6 Slides were original prepared by Dr. Tatsuya Suda.
IPv6 Network Security.
2: Comparing IPv4 and IPv6 Rick Graziani Cabrillo College
Umut Girit  One of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer.
PANA Requirements and Terminology - IETF54 -. PANA WG, IETF 54, Requirements and Terminology draft-ietf-pana-requirements-02.txt Changes Comments/questions.
BGP.
IETF 58 PANA WG PANA Update and Open Issues (draft-ietf-pana-pana-02.txt) Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin.
K. Salah 1 Chapter 31 Security in the Internet. K. Salah 2 Figure 31.5 Position of TLS Transport Layer Security (TLS) was designed to provide security.
IP/ICMP Translation Algorithm (IIT) Xing Li, Congxiao Bao, Fred Baker
CMPT 471 Networking II Address Resolution IPv6 Neighbor Discovery 1© Janice Regan, 2012.
12/05/2007IETF70 PANA WG1 PANA Network Selection draft-ohba-pana-netsel-00.txt Yoshihiro Ohba.
March 20, 2006IETF65 PANA WG PANA Specification Updates (draft-ietf-pana-pana-11.txt) Yoshihiro Ohba
7/14/2003IETF57 PANA enabling IPsec based Access control draft-mohanp-pana-ipsec-00.txt Mohan Parthasarathy Tahoe Networks - Presented by Hannes Tschofenig.
1 CMPT 471 Networking II IGMP (IPv4) and MLD (IPv6) © Janice Regan,
UNIT IP Datagram Fragmentation Figure 20.7 IP datagram.
August 1, 2005IETF63 PANA WG Pre-authentication Support for PANA (draft-ohba-pana-preauth-00.txt) Yoshihiro Ohba
SYSTEM ADMINISTRATION Chapter 8 Internet Protocol (IP) Addressing.
Authentication Mechanism for Port Control Protocol (PCP) draft-wasserman-pcp-authentication-01.txt Margaret Wasserman Sam Hartman Painless Security Dacheng.
IETF-71, Philadelphia PANA in DSL networks draft-morand-pana-panaoverdsl-01.txt Lionel Morand France Telecom Alper Yegin Samsung Yoshihiro Ohba Toshiba.
SHIM6 Protocol Drafts Overview Geoff Huston, Marcelo Bagnulo, Erik Nordmark.
1 Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display. Dynamic Host Configuration Protocol (DHCP)
Chapter 22 Bootstrap and Auto configuration (DHCP) History of Bootstrap -Bootstrap is used to assign IP address to the computer. -Constant changes in the.
3/20/2007IETF68 PANA WG1 PANA Issues and Resolutions Yoshihiro Ohba Alper Yegin.
PANA Framework Prakash Jayaraman, Rafa Marin Lopez, Yoshihiro Ohba, Mohan Parthasarathy, Alper Yegin IETF 59.
Draft-ietf-fecframe-config-signaling-02 1 FEC framework Configuration Signaling draft-ietf-fecframe-config-signaling-02.txt IETF 76 Rajiv Asati.
Multi-hop PANA IETF Currently: –“For simplicity, it is assumed that the PAA is attached to the same link as the device (i.e., no intermediary IP.
IETF 57 PANA WG PANA Discussion and Open Issues (draft-ietf-pana-pana-01.txt) Dan Forsberg, Yoshihiro Ohba, Basavaraj Patil, Hannes Tschofenig, Alper Yegin.
DSLF Subscriber Auth Requirements and IETF PANA Protocol PANA WG Chairs IETF 70 Dec 7, 2007 – Vancouver, Canada.
Nov. 9, 2004IETF61 PANA WG PANA Specification Last Call Issues Yoshihiro Ohba, Alper Yegin, Basavaraj Patil, D. Forsberg, Hannes Tschofenig.
IETF69 PANA WG Victor Fajardo, Yoshihiro Ohba and Rafael Marin Lopez PANA State Machine Issue Resolution (draft-ietf-pana-statemachine-05.txt)
DHCPv4 option for PANA Authentication Agents draft-suraj-dhcpv4-paa-option-00.txt DHC/PANA WG IETF-63 France, Paris.
PANA in DSL networks draft-morand-pana-panaoverdsl-00.txt Lionel Morand Roberta Maglione John Kaippallimalil Alper Yegin IETF-67, San Diego.
7/24/2007IETF69 PANA WG1 PANA Issues and Resolutions draft-ietf-pana-pana-17.txt draft-ietf-pana-framework-09.txt Yoshihiro Ohba Alper Yegin.
1 K. Salah Module 5.1: Internet Protocol TCP/IP Suite IP Addressing ARP RARP DHCP.
EAP Applicability IETF-86 Joe Salowey. Open Issues Open Issues with Retransmission and re- authentication Remove text about lack of differentiation in.
1 Chapter 24 Internetworking Part 4 (Transport Protocols, UDP and TCP, Protocol Port Numbers)
1 CMPT 471 Networking II OSPF © Janice Regan,
Chapter 9: Transport Layer
Networks Problem Set 3 Due Nov 10 Bonus Date Nov 9
Denial of Service attack in IPv6 networks and Counter measurements
<draft-ohba-pana-framework-00.txt>
Instructor Materials Chapter 9: Transport Layer
Open issues with PANA Protocol
PANA in DSL networks draft-morand-pana-panaoverdsl-01.txt
PANA Discussion and Open Issues (draft-ietf-pana-pana-01.txt)
PAA-EP protocol considerations PANA wg - IETF 57 Vienna
Introduction to Networking
TCP Transport layer Er. Vikram Dhiman LPU.
Chapter 5 Network and Transport Layers
Chapter 4: Access Control Lists (ACLs)
March 2012 doc.: IEEE March 2012 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Guide to TCP/IP Fourth Edition
PANA Implementation in Open Diameter
Setting Up Firewall using Netfilter and Iptables
Robert Moskowitz, Verizon
Robert Moskowitz, Verizon
Robert Moskowitz, Verizon
Robert Moskowitz, Verizon
Robert Moskowitz, Verizon
Net 323 D: Networks Protocols
Internet Protocol, Version 6 (IPv6)
1 Multi-Protocol Label Switching (MPLS). 2 MPLS Overview A forwarding scheme designed to speed up IP packet forwarding (RFC 3031) Idea: use a fixed length.
doc.: IEEE /454r0 Bob Beach Symbol Technologies
802.11i Bootstrapping Using PANA
PAA-2-EP protocol PANA wg - IETF 58 Minneapolis
IPv4 Addressing By, Ishivinder Singh( ) Sharan Patil ( )
Lecture 4a Mobile IP 1.
Computer Networks Protocols
Presentation transcript:

PANA Issues and Resolutions Yoshihiro Ohba Alper Yegin 11/6/2006 IETF67 PANA WG

Status Going through AD review after IETF Last Call Waiting for external review on language tag usage in Notification AVP PANA is getting more simplified Only technical issues are presented here 11/6/2006 IETF67 PANA WG

Session-Id Issue: Globally unique session identifier is not needed 4-octet session identifier locally unique within PAA is sufficient Proposed resolution: Define 4-octet Session-Id field in PANA message header and remove Session-Id AVP A new Session-Id is assigned by PAA and carried in PSR/PSA exchange The assigned Session-Id is carried in subsequent messages throughout the session Remove PANA_UNKNOWN_SESSION_ID result code (message with unknown Session-ID should be silently discarded without generating a PER) 11/6/2006 IETF67 PANA WG

Stateless handshake : Issue Proposed resolution: Do we need an optional “stateless” mode (marked with “L-bit”?) Whether stateless or stateful mode, there is at least minimum state that needs to be maintained (cookie, initial sequence number). Adding PSR retransmission to this state is not a big issue. Proposed resolution: Remove the distinction between the stateless and stateful mode Remove Cookie AVP Use Session-Id for testing reachability of PaC test PaC needs to receive PSR to generate PSA with a valid Session-Id Remove L-flag PSR retransmission MAY be turned off if PAA wants to be stateless PaC retransmits PCI until it receives PANA-Auth-Request PSA retransmission is not needed PaC PAA PCI PSR PSA PAR : 11/6/2006 IETF67 PANA WG

Device identifier Issue: Can we limit the device ID to IP address (so that we don’t get into L2 addresses and locally-significant addresses)? Proposed resolution: Remove the DI determination from the spec. Leave it to other specs (architectures) using PANA Remove device identifier definition from Section 2 Remove Device-Id AVP Remove “Device-Id Choice” Section 11/6/2006 IETF67 PANA WG

Bootstrapping lower-layer Issue: Bootstrapping functionality should be removed from base specification Proposed resolution Remove Protection-Capability AVP Remove “PaC-EP-Master-Key” section 11/6/2006 IETF67 PANA WG

Post-PANA address configuration Issue: Post-PANA Address Configuration (PPAC) should be removed from PANA specification Discussion: IP address configuration is an orthogonal and out-of scope issue for PANA Each address configuration protocol has own re-configuration notification from network or equivalent Proposed resolution Remove PPAC AVP Remove Appendix A 11/6/2006 IETF67 PANA WG

Network selection Issue: Network selection can be better defined in a separate I-D to simplify the base specification Use of RADIUS operator identifier has been proposed in place of SMI vendor id, but still needs discussion Proposed resolution: Remove network selection functionality Remove Provider-Identifier, Remove Provider-Name, NAP-Information and ISP-Information AVPs Remove “Network Selection” Section 11/6/2006 IETF67 PANA WG

Nonce AVP Issue: Protocol can be simplified by always carrying Nonce AVP in the first PAR/PAN exchange (and not in PSR/PSA at all) This also allows fresh nonces to be used for re-keying PANA_AUTH_KEY in re-authentication phase Proposed resolution: Remove Nonce AVP from PSR and PSA Specify that Nonce AVP is carried only in the first PAR/PAN exchange in both authentication and authorization phase and re-authentication phase 11/6/2006 IETF67 PANA WG

Filtering exceptions Issue: Needs text for describing that EP needs to pass certain IP packets (e.g., DHCP) that are needed for PANA even for unauthorized client Proposed resolution: Add the following sentence in EP definition: "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.)." 11/6/2006 IETF67 PANA WG

EAP message duplication handling Issue: EAP message duplication is handled by EAP layer, so PANA does not need to handle it Proposed resolution: Remove the last paragraph (quoted below) of Section 5.2 “PANA MUST NOT generate EAP message duplication. EAP payload of a retransmitted PANA message MUST NOT be passed to the EAP layer.” 11/6/2006 IETF67 PANA WG

IP source/destination address Issue: The following sentence in Section 6.1 is too obvious “The source and destination addresses SHOULD be set to the addresses on the interfaces from which the message will be sent and received, respectively.” Proposed solution: Remove the sentence 11/6/2006 IETF67 PANA WG

UDP port numbers Current rule: For response: (Src,Dst) := (Dst,Src) of request For others: Src := Sender-generated port number Dst := Dst of previously sent msg or well-known (IANA-assigned) port number Issue: Why not always use well-known port number for destination port? Discussion: Use of an ephemeral port number contained in a request as destination port of a response is common (e.g., Mobile IPv4) But it would make filtering PANA messages at firewall difficult Proposal: Always use well-known port number in either src or dst port For response: Same as current rule Dst := well-known port number 11/6/2006 IETF67 PANA WG

AVP/Message Allocation Policy Issue: Clarification is needed on allocation policy for a new mandatory-supported AVP or a new message IANA namespace would be needed for Version field as well Discussion: A new mandatory-supported AVP or a new message used for a mandatory-supported feature would require a new version of PANA specification Proposed resolution: Add “Standards Action” for AVP Code and Message Type allocation policy Add text in Section 10 to cover the discussion Add IANA namespace for Version field, with Standards Action required 11/6/2006 IETF67 PANA WG

PANA-Error-Request Issue: PER needs to contain information on which message caused an error, in addition to which AVP caused an error Proposed resolution: Define Failed-Message-Header AVP to be contained in PER Type: Octetstring Length: 12 Contents: The header of erroneous message 11/6/2006 IETF67 PANA WG

Additional condition to terminate request retransmission Issue: Request retransmission should be stopped when a protected PER for the request is received Proposed resolution: Revise Section 9 to have the additional condition for terminating request retransmission 11/6/2006 IETF67 PANA WG

Other changes Reassign Result-Code AVP values Authentication Result Codes: 0 (success),1 (auth failure), 2 (authz failure) Protocol Error Result Codes: 1001, 1002, … Increase the number of experimental Message Types from 2 to 16 Change AVP Code allocation policy for not allowing the exception of not requiring IETF Consensus for allocating just one or two AVP Even a single AVP allocation requires IETF Consensus Don’t use Vendor-Id=0 for IETF assigned AVPs. Use absence of Vendor-Id for that purpose 11/6/2006 IETF67 PANA WG

Thank you! 11/6/2006 IETF67 PANA WG

Filtering exceptions Issue: Needs text for describing that EP needs to pass certain IP packets (e.g., DHCP) that are needed for PANA even for unauthorized client Proposed resolution: Add the following sentence in EP definition: (another version) "EPs should prevent data traffic from and to any unauthorized client. This specification concerns itself only with the case that any address allocation., ND, etc. traffic does not need to pass thorough the EP." 11/6/2006 IETF67 PANA WG