Skip to main content

Deep Dive into IPv6 Extension Header Testing
draft-elkins-v6ops-eh-deepdive-fw-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Nalini Elkins , michael ackermann , Dhruv Dhody
Last updated 2022-09-30
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-elkins-v6ops-eh-deepdive-fw-00
Internet Engineering Task Force                                N. Elkins
Internet-Draft                                              M. Ackermann
Intended status: Best Current Practice                       INT Council
Expires: 3 April 2023                                           D. Dhody
                                      India Internet Engineering Society
                                                       30 September 2022

              Deep Dive into IPv6 Extension Header Testing
                draft-elkins-v6ops-eh-deepdive-fw-00.txt

Abstract

   IPv6 Extension Header testing is a complex area.  Studies have shown
   varying results.  This document proposes a methodology for isolating
   the location and reasons for IPv6 Extension Headers blockage.  This
   document outlines the basic framework and set of documents which will
   follow.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 3 April 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Elkins, et al.            Expires 3 April 2023                  [Page 1]
Internet-Draft       Deep Dive into IPv6 EH-Testing       September 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Problem Description . . . . . . . . . . . . . . . . . . .   2
     1.2.  Fundamental Premises  . . . . . . . . . . . . . . . . . .   3
     1.3.  Diagnostic Methodology Overview . . . . . . . . . . . . .   4
   2.  EH Enabled Server / Client / Router . . . . . . . . . . . . .   5
     2.1.  Modifications to send EHs with application data . . . . .   5
     2.2.  Crafting packets with EH headers  . . . . . . . . . . . .   5
     2.3.  How to Add EH . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Which EH to Use . . . . . . . . . . . . . . . . . . . . .   7
   3.  Rate of sending and sampling  . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

1.1.  Problem Description

   IPv6 Extension Headers (EHs) may be blocked at various points yet
   show the same symptom.  That is, if an EH is blocked at a router, it
   will appear to the client or measurement technique that the packet is
   dropped.  If an EH is blocked at a load balancer or CDN, the client
   will see the same symptom -- the packet is dropped.

   This is a problem because when the same symptom can be the due to
   multiple factors, incorrect conclusions may be drawn from the
   results.  That is, if, for example, loss of the sense of taste of
   sweetness can be due either to a brain tumor or a minor neurological
   problem, then if someone has a tendency towards hypochondria, they
   may incorrectly bemoan their impending death from a brain tumor when
   it may really be only a minor issue.

Elkins, et al.            Expires 3 April 2023                  [Page 2]
Internet-Draft       Deep Dive into IPv6 EH-Testing       September 2022

   This is the same for EH testing.  If a packet is seen to be dropped
   in measurement, it may only be that there is a bug in the load
   balancer code (for example) and not that EH transmission does not
   work writ large.

   This document proposes a framework to isolate the problem of where
   the packet is being dropped.  This is, however, more easily said than
   done.  There are many components and devices in a network.  Each may
   require a different isolation technique.

   We propose a methdology which starts with the simplest topology and
   grows towards more and more complex, real-world networks.  For
   example, in today's networks, if one attempts to access a well-known
   site such as Facebook.com, one is likely to access a cache server
   managed by a Content Delivery Network (CDN) rather than the origin
   server managed by Facebook.  It is important to isolate the testing
   so that we can determine the exact component which may be blocking
   the EH and why.

   We additionally discuss the potential issues with the type of data
   sent as well as how the way the data is sent for testing may impact
   test results.

1.2.  Fundamental Premises

   Yet, there are some overriding principles.

   The blockage may be:

   - in the source network
   - in the destination network
   - in a transit network

   Then:

   - it may be blocked intentionally
   - it may be blocked unintentionally

   Intentional blocks are easier to assess.  The block is an
   administrator or network policy.  Of course, the policy may come
   about as a result of a misunderstanding of the function of EHs or
   lack of effective guidance but nonetheless, this is an understandable
   decision.

   The more troubling causes of EH blocks include:

   - bugs
   - default configurations or policies by the vendor

Elkins, et al.            Expires 3 April 2023                  [Page 3]
Internet-Draft       Deep Dive into IPv6 EH-Testing       September 2022

   - lack of support of EH or IPv6 itself

   As far as the blocking component itself (whether intentional or
   unintentional):

   - may be a router
   - may be a firewall
   - may be a load balancer
   - may be a proxy
   - may be a Host OS
   - may be a DNS or other configuration setting

   Note: A DNS or other configuration setting may block IPv6 or prefer
   IPv4.  If not tested correctly, lack of support for IPv6 itself may
   incorrectly appear as lack of support for EHs.

   Finally, the blockage or source may differ based on the type of EH.
   Some EHs are limited to an administrative domain, some EHs are
   processed at every hop, still others are from the source and
   destination.  Problem isolation techniques will differ for the
   various classes of EH.

   Our final document in this series will be a BCP to indicate which EH
   should be allowed, blocked, encrypted, or authenticated and at which
   component or platform.

   Note: [RFC9288] "Recommendations on the Filtering of IPv6 Packets
   Containing IPv6 Extension Headers at Transit Routers" focuses on the
   IPv6 EH handling at transit routers only.  Our approach is to produce
   a final BCP with various recommendations across network segments,
   once the nature of the problems and techniques for isolation are well
   known.

1.3.  Diagnostic Methodology Overview

   The diagnostic methodology to follow depends on what is being tested.
   For example, the problem isolation for a CDN would be different than
   the problem isolation for an internal network.

   This framework proposes the following set of documents:

   - EH problem isolation for owned client / server
   - EH problem isolation in a network using a CDN
   - EH problem isolation in a network using a cloud provider
   - EH problem isolation for routers
   - EH problem isolation for load balancers
   - EH problem isolation for proxies
   - EH problem isolation for host OSs

Elkins, et al.            Expires 3 April 2023                  [Page 4]
Internet-Draft       Deep Dive into IPv6 EH-Testing       September 2022

   - EH problem isolation for transit networks
   - EH problem isolation for ISPs (multiple components / networks)
   - BCP for EH Permissions, Encryption and Authentication

2.  EH Enabled Server / Client / Router

   The first step for all testing is to have a test server, client and /
   or router enabled to send EHs.  There are two basic options to do
   this, each with its own set of advantages and drawbacks.

   The options fall broadly into two categories:

   - Modifications to the OS / interface / socket / driver to send EHs
   with application data
   - Using a package which crafts EHs (multiple exist)

   If crafting packets, then the question arises of which packets to
   craft.  This will be discussed in section 2.2.

   For either methodology, the rate of sending may influence results.
   This will be discussed in section 3.

2.1.  Modifications to send EHs with application data

   Possibly the best way to isolate problems with EHs may be to have a
   server, client or router which has modifications to the OS,
   interface, driver or other to send real EHs with real application
   data.  This carries the initial cost of creating such modifications
   since, unfortunately, the current set of host OSs do not natively
   support this.

   The reason we find this to be the best method is because the problem
   of what packet to craft is a field which is rife with land mines.
   See Section 2.2 for a further discussion of the exact nature of the
   aforesaid land mines.

2.2.  Crafting packets with EH headers

   A number of packages exist which can craft a packet with an EH
   header.  The more interesting and fraught problem may be which exact
   packet to craft and then which EH to craft.

   Let's discuss first the options for the type of packet to craft.
   These include:

   - A TCP packet
   - A UDP packet
   - An ICMPv6 packet

Elkins, et al.            Expires 3 April 2023                  [Page 5]
Internet-Draft       Deep Dive into IPv6 EH-Testing       September 2022

   - A QUIC packet

   If crafting a TCP packet, then it is likely that some middlebox will
   drop a TCP packet which does not have the appropriate ACK and
   SEQUENCE numbers.  One may get around this problem by sending a
   packet with the SYN flag on and directed to some well-known port such
   as 443 or 80.  But, if many firewalls and other devices such as IDS /
   IPS, and even some OSs have SYN Flood protection.  So, if more than a
   certain number of these packets, say 10, in some short interval are
   sent, then they are likely to be dropped for reasons other than
   blockage of EH headers.

   One may choose to use UDP, QUIC, or ICMPv6 to attempt to bypass the
   complexities of TCP.  Some enterprise networks are likely to drop UDP
   and / or QUIC.  Testing should be done without EH to make sure that
   such packets do indeed pass.

   Certainly, if you have access to all the middleboxes in your domain,
   you may be able to bypass or stop SYN Flood, UDP, ICMPv6 or other
   transport layer blocks at all the middleboxes.  But, it may be a more
   difficult effort than might be imagined.

   You may wish to test in a lab environment first to validate your
   approach.

2.3.  How to Add EH

   There are two ways to add an EH to a packet:

   - use a "real" EH
   - craft an EH

   The best method may be to use an EH which is actually processed at
   the client, server, and any associated router.  This leaves us with a
   sparse set to choose from.  The problem with crafting an EH is that
   if the data is not "real", one may not be able to fault a network
   component for blocking it.

   Having said that, let's discuss crafting an EH.  An EH may be crafted
   by simply using multiple PADN options.  One should be careful not to
   use too many PADNs because then this type of header may be dropped by
   a middlebox or OS as being a flawed packet.  This is likely to
   distort the results.

   An EH with all 0's or other data patterns that could be perceived as
   not "real" may also be dropped by middleboxes which are trying to be
   helpful.

Elkins, et al.            Expires 3 April 2023                  [Page 6]
Internet-Draft       Deep Dive into IPv6 EH-Testing       September 2022

   It is also possible that the length of the EH may have some effect on
   what EHs get dropped and where.

   You may wish to try this in a lab environment first.  If the test
   suceeds, then you may test on your network.

2.4.  Which EH to Use

   Next, there is a consideration that the type of EH, for example,
   Destination Options, Hop-by-hop, etc. could get processed differently
   and may be dropped at different frequencies, by different devices.
   You may wish to test one at a time and note the results.

   You may wish to try this in a lab environment first.  If the test
   suceeds, then you may test on your network.

3.  Rate of sending and sampling

   Whether you have chosen to send real application data or to craft
   packets, the rate of sending and sampling may create a false
   indication of blockage.  That is, if you send a great deal of data at
   frequent intervals, some middlebox in the network is likely to see
   this traffic as a Denial of Service (DoS) attack and block it.  This
   is more likely if a great many crafted packets are sent but even with
   real application data such as FTP or HTTP, overly aggressive sending
   is likely to be counterproductive.

   You may wish to send only a few packets or one or two CURL or FTPs at
   any one test.

4.  Security Considerations

   This document has no security considerations.

5.  Privacy Considerations

   This document has no privacy considerations.

6.  IANA Considerations

   This memo includes no request to IANA.

      

Elkins, et al.            Expires 3 April 2023                  [Page 7]
Internet-Draft       Deep Dive into IPv6 EH-Testing       September 2022

7.  References

7.1.  Normative References

7.2.  Informative References

[RFC9288]  Gont, F., Liu, W., "Recommendations on the Filtering 
           of IPv6 Packets Extension Headers at Transit Routers", 
           RFC 9388, Aug. 2022,
           <https://datatracker.ietf.org/doc/rfc9288/>.

Contributors

   TBD

Authors' Addresses

   Nalini Elkins
   Industry Network Technology Council
   United States of America
   Phone: +1 831 234 4232
   Email: nalini.elkins@insidethestack.com

   Michael Ackermann
   Industry Network Technology Council
   United States of America
   Phone: +1 248 703 3600
   Email: mackermann@bcbsm.com
   URI:   http://www.bcbsm.com

   Dhruv Dhody
   India Internet Engineering Society
   Email: dhruv.ietf@gmail.com

Elkins, et al.            Expires 3 April 2023                  [Page 8]