1 / 30

SFD Text for Upper Layers

SFD Text for Upper Layers. Authors:. Date: 2012-0 5 - 14. Abstract. DCN: IEEE11-12/ 0273r8 Title: SFD Text for Higher Layers Authors and Companies: Hiroki Nakano (Trans New Technology, Inc. ) Hitoshi Morioka (Allied Telesis R&D Center) Scope: Upper layer

wei
Download Presentation

SFD Text for Upper Layers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SFD Text for Upper Layers Authors: • Date: 2012-05-14 Hiroki Nakano, Trans New Technology, Inc.

  2. Abstract • DCN: IEEE11-12/0273r8 • Title: SFD Text for Higher Layers • Authors and Companies: • Hiroki Nakano (Trans New Technology, Inc.) • Hitoshi Morioka (Allied Telesis R&D Center) • Scope: Upper layer • Motivation: page 3 (abstract) • Background information: page 4-22 • Motion: page23-27 including five motions Hiroki Nakano, Trans New Technology, Inc.

  3. Motivation • An IP(v4) address are normally assigned by DHCP(v4) and the specification of DHCP is stable. DHCP includes definition of state transition and have lots of extensions derived from lots of past discussions. Non-AP STA should be still a DHCP client. • The discussions of IPv6 address assignment are still going on actively in IETF and its specification is being changed. We should provide a framework for them. • In addition, TGai should not deny the other protocols because we are the link layer. Hiroki Nakano, Trans New Technology, Inc.

  4. Background Information • Common abbreviation: • DHCP: Dynamic Host Configuration Protocol, which is defined by RFC2131 and the other supplemental RFCs. Hiroki Nakano, Trans New Technology, Inc.

  5. The past Straw poll 1 Do you support to add the following text to the clause 4 of SFD: • “The TGai amendment defines a method of IP(v4) address assignment which works as a transport of DHCP.” Yes: 5 No: 3 Don’t care: 17 (Mar 15 AM1) Hiroki Nakano, Trans New Technology, Inc.

  6. The past Straw poll 2 Do you support to add the following text to the clause 4 of SFD: • “The TGai amendment defines a generalized method for upper layer transport encapsulation during FILS to enable higher layer services.” Yes: 7 No: 1 Don’t care: 22 (Mar 15 AM1) Hiroki Nakano, Trans New Technology, Inc.

  7. Proposed Amendment 1 • Clause to amend: Section 3 • Add to the last of Section 3: • 3.x Encapsulation Framework for HLCF • The TGai amendment defines a generalized method for upper layer transport encapsulation during FILS to enable higher layer services. Hiroki Nakano, Trans New Technology, Inc.

  8. Motivation of Proposed Amendment 1 • This sentence intends TGai to support IPv4, IPv6 and other upper layer protocols. • Transparency as a link layer is important in order to support various upper layer protocols. Hiroki Nakano, Trans New Technology, Inc.

  9. Proposed Amendment 2 • Clause to amend: Section 5 • Add to the last: • 5.x IPv4 support • The TGai amendment defines a method of IP(v4) address assignment which works as a transport of DHCP. Hiroki Nakano, Trans New Technology, Inc.

  10. Proposed Amendment 2 (Supplement) • Clause to amend: Section 2 • Add to appropriate line: • DHCP: Dynamic Host Configuration Protocol, which is defined by RFC2131 and the other supplemental RFCs. Hiroki Nakano, Trans New Technology, Inc.

  11. Motivation of Proposed Amendment 2 • This sentence intends TGai to provide standard implementation technique of IP(v4) address assignment by DHCP. Our PAR says TGai is required to support “IP address assignment”as an example. • The specification of DHCP is quite stable and widely deployed, therefore it is eligible to be referred by TGai. • The following slides show that a function as a transport is sufficient to achieve the goal of TGai. Hiroki Nakano, Trans New Technology, Inc.

  12. Prerequisite • DHCP with RCO have ability to complete an IP address assignment with a round-trip exchange of frames. • DHCP: Dynamic Host Configuration Protocol (RFC2131) • RCO: Rapid Commit Option define (RFC4039) Hiroki Nakano, Trans New Technology, Inc.

  13. Hiroki Nakano, Trans New Technology, Inc. Sequence Example by DHCP with RCO Non-AP STA AP DHCP server DHCP Client Software DHCP Discover w/ RCO AS AP keeps a DHCP packet. Maximum time is assumed to be less than 100 msec. Processing for security (See TGai Functional Requirements) less than 100ms At this point, Non-AP STA has been authenticated. DHCP Ack

  14. Comments & Answers • Frames get bigger. It’s the problem. • TGai intends to reduce exchanges of packets, not reduce information itself. Therefore, it is natural that less exchanges leads to bigger packets. A round trip of 1000-byte-long frames is obviously preferable to 10 round trips of 100-byte-length packets. • TGai can provide special “compression” encodings for specific upper layer protocols, such as DHCP. For instance, most of DHCP packets have about 200-byte-long consecutive zeros and a generic data compression technique or a special encoding for DHCP can compress DHCP packets without changing information. Hiroki Nakano, Trans New Technology, Inc.

  15. Comments & Answers • What packets should be forwarded or not? Does it affect security? • Basically, piggybacked frames of upper layers should be forwarded after authentication is finished. Essentially, non-AP STA can throw any kind of packets for upper layers after authentication. • If you want a further optimization such as a premature start of IP address assignment processing before completion of authentication, you must consider security mechanism such as packet filtering. However, this is out of our scope, although TGai does not prevent such techniques. Hiroki Nakano, Trans New Technology, Inc.

  16. Comments & Answers • How long does an AP wait for a response from DHCP server? • The TGai Functional Requirements document requests to provide a secure link set-up in less than 100 ms. • Therefore, Maximum time for an AP to wait is 100ms. • DHCP packets transfer between an AP and a non-AP STA in a normal manner after 802.11ai link setup. If a response from DHCP server reaches an AP after the AP sends a response to non-AP STA, DHCP packets can be sent in the same manner as Data frames. Hiroki Nakano, Trans New Technology, Inc.

  17. Comments & Answers • Do APs require to keep HLCF (DHCP) packets during processing for security? Does this enable attackers to consume memory of APs? • TGai assumes that each authentication for each non-AP STA is finished within 100ms. See Section 2.2.1 “Link Set-Up Time” of TGai Functional Requirements (IEEE 11-11/0745r5) • Our media 802.11 can transfer 5000 packets per second at most. • The size of a HLCF packet is 1500 byte at most. • MTU of 802.11 is about 2300 byte. • Therefore, amount of packets for AP to keep is 750KB at most in case that all packets flying are employed for attacks. Hiroki Nakano, Trans New Technology, Inc.

  18. Comments & Answers • The specific name of a protocol, e.g. “DHCP”, is not suitable for SFD! • DHCP is obviously the most deployed protocol in protocols for IP address assignment function on the 802 network. Hiroki Nakano, Trans New Technology, Inc.

  19. Proposed Amendment 3 • Clause to amend: Section 5 • Add to the last: • 5.x IPv6 support • The TGai amendment does not define any detail of IPv6 address assignment and does encourage IPv6 to use a generalized method for upper layer transport encapsulation defined by the TGai amendment. Hiroki Nakano, Trans New Technology, Inc.

  20. Motivation of Proposed Amendment 3 • The discussions of IPv6 address assignment are still going on actively in IETF and its specification is being changed. We should provide a framework for them. Hiroki Nakano, Trans New Technology, Inc.

  21. Proposed Amendment4 • Clause to amend: Section 5 • Add to the last of Section 5: • 5.xForwardingof HLCF information • The TGai amendment defines HLCF as an APforwards informationcarried from an non-AP STA by HLCF to the others than the non-AP STA only either after successful authentication orwith assurances of the same security level as the existing802.11 security framework. Hiroki Nakano, Trans New Technology, Inc.

  22. Motivation of Proposed Amendment 4 • Any request prohibits to be processed before it is validated. Hiroki Nakano, Trans New Technology, Inc.

  23. Motion 1 Move to add the following text to theSection 3 of SFD: • “3.x Encapsulation Framework for HLCF • The TGai amendment defines a generalized method for upper layer transport encapsulation during FILS to enable higher layer services.” Moved: Seconded: Yes: No: Abstain: Hiroki Nakano, Trans New Technology, Inc.

  24. Motion 2 • Move to add the following text to theSection 5 of SFD: • “5.x IPv4 support • The TGai amendment defines a method of IP(v4) address assignment which works as a transport of DHCP.” Moved: Seconded: Yes: No: Abstain: Hiroki Nakano, Trans New Technology, Inc.

  25. Motion 2a • Move to add the following text to theSection 2 of SFD: • “DHCP: Dynamic Host Configuration Protocol, which is defined by RFC2131 and the other supplemental RFCs.” Moved: Seconded: Yes: No: Abstain: Hiroki Nakano, Trans New Technology, Inc.

  26. Motion 3 • Move to add the following text to theSection 5 of SFD: • “5.x IPv6 support • The TGai amendment does not define any detail of IPv6 address assignment and does encourage IPv6 to use a generalized method for upper layer transport encapsulation defined by the TGai amendment.” Moved: Seconded: Yes: No: Abstain: Hiroki Nakano, Trans New Technology, Inc.

  27. Motion 4 • Move to add the following text to theSection 5 of SFD: • “5.xForwardingof HLCF information The TGai amendment defines HLCF as an APforwards higher layer informationbetween an non-AP STA and the others than the non-AP STA only either after successful authentication orwith assurances of the same security level as the existing802.11 security framework.” Moved: Seconded: Yes: No: Abstain: Hiroki Nakano, Trans New Technology, Inc.

  28. Backup Hiroki Nakano, Trans New Technology, Inc.

  29. Hiroki Nakano, Trans New Technology, Inc. Apossible counterproposal Non-AP STA AP DHCP server New software for new protocol TGai new protocol Processing for security Translation? DHCP Discover w/ RCO Translation? DHCP Ack TGai new protocol

  30. Comparison Hiroki Nakano, Trans New Technology, Inc.

More Related