Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-eh-filtering-07.txt

From: [email-masked]
Date: Tue, 19 Jan 2021 13:48:04 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure WG of the IETF.

        Title           : Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers
        Authors         : Fernando Gont
                          Will(Shucheng) Liu
	Filename        : draft-ietf-opsec-ipv6-eh-filtering-07.txt
	Pages           : 37
	Date            : 2021-01-19

Abstract:
   This document analyzes the security implications of IPv6 Extension
   Headers and associated IPv6 options.  Additionally, it discusses the
   operational and interoperability implications of discarding packets
   based on the IPv6 Extension Headers and IPv6 options they contain.
   Finally, it provides advice on the filtering of such IPv6 packets at
   transit routers for traffic *not* directed to them, for those cases
   where such filtering is deemed as necessary.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-07
https://datatracker.ietf.org/doc/html/draft-ietf-opsec-ipv6-eh-filtering-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-eh-filtering-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Dougherty <[email-masked]>
Date: Thu, 21 Jan 2021 01:31:31 +0000

Greetings,

This was an interesting topic and write up. I have a few comments related to writing structure and readability.

Original:
While some operators "officially" drop packets that contain IPv6 EHs, it is possible that some of the measured packet drops be the result of improper configuration defaults, or inappropriate advice in this area.

Suggestion:
While some operators "officially" drop packets that contain IPv6 EHs; it is possible that some of the measured packet drops be the result of improper configuration defaults, or inappropriate advice in this area.

Original:
The advice in this document is aimed only at transit routers that may
   need to enforce a filtering policy based on the EHs and IPv6 options
   a packet may contain, following a "deny-list" approach, and hence is
   likely to be much more permissive that a filtering policy to be
   employed at e.g. the edge of an enterprise network.  

Suggestion:
The advice in this document is aimed only at transit routers that may
   need to enforce a filtering policy based on the EHs and IPv6 options
   a packet may contain, following a "deny-list" approach, and hence is
   likely to be much more permissive than a filtering policy to be
   employed at, e.g., the edge of an enterprise network.  

Original:
Section 4.2, first paragraph, second sentence
Essentially, packets that contain IPv6 options might need to be processed by an IPv6 router's general-purpose CPU,and hence could present a DDoS risk to that router's general-purpose CPU (and thus to the router itself).

Suggestion:
Essentially, packets that contain IPv6 options that might need to be processed by an IPv6 router's general-purpose CPU and could present a DDoS risk to that router's general-purpose CPU.

Comments:
1 - Within the last sentence of the third paragraph within the "Introduction" sections. There is a comment about "inappropriate and missing guidelines". Who dictates or decides what is inappropriate?
2 - First bullet point in Section 2.3, change "recognise" to "recognize" 
3 - Within the last paragraph of section 2.3, part of the comment ".... it is generally desirable that the sender be signaled of the packet drop...." While the idea is valid, it might be a good idea to note that such a signal might attract malicious attention or threat-actors.
4 - Section 3.4.4.4. It might be best to specify what type of IPSEC deployment is involved, host-to-host, site-to-site, site-to-host? 
5 - Section 3.4.5.5. Advise, hasn't AH been depreciated as an insecure methodology versus ESP?
  
Thank you for your kind attention,

Michael Dougherty

On 1/19/21, 4:48 PM, "[email-masked]" <[email-masked]> wrote:

    Abstract:

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Jan 2021 02:42:24 -0300

Hello, Michael,

Thanks a lot for your input! In-line...

On 20/1/21 22:31, Michael Dougherty wrote:
> Greetings,
> 
> This was an interesting topic and write up. I have a few comments
> related to writing structure and readability.
> 
> Original: While some operators "officially" drop packets that contain
> IPv6 EHs, it is possible that some of the measured packet drops be
> the result of improper configuration defaults, or inappropriate
> advice in this area.
> 
> Suggestion: While some operators "officially" drop packets that
> contain IPv6 EHs; it is possible that some of the measured packet
> drops be the result of improper configuration defaults, or
> inappropriate advice in this area.

Wouldn't the s/,/;/ make the two sentences more unrelated, when they are 
actually meant to be closely-related?

> Original: The advice in this document is aimed only at transit
> routers that may need to enforce a filtering policy based on the EHs
> and IPv6 options a packet may contain, following a "deny-list"
> approach, and hence is likely to be much more permissive that a
> filtering policy to be employed at e.g. the edge of an enterprise
> network.
> 
> Suggestion: The advice in this document is aimed only at transit
> routers that may need to enforce a filtering policy based on the EHs
> and IPv6 options a packet may contain, following a "deny-list"
> approach, and hence is likely to be much more permissive than a
> filtering policy to be employed at, e.g., the edge of an enterprise
> network.

Will do!

> 
> Original: Section 4.2, first paragraph, second sentence Essentially,
> packets that contain IPv6 options might need to be processed by an
> IPv6 router's general-purpose CPU,and hence could present a DDoS risk
> to that router's general-purpose CPU (and thus to the router
> itself).
> 
> Suggestion: Essentially, packets that contain IPv6 options that might
> need to be processed by an IPv6 router's general-purpose CPU and
> could present a DDoS risk to that router's general-purpose CPU.

Will do.

> 
> Comments: 1 - Within the last sentence of the third paragraph within
> the "Introduction" sections. There is a comment about "inappropriate
> and missing guidelines". Who dictates or decides what is
> inappropriate?

Well, that's indeed subjective. One might say that, for example, "drop 
all packets with EHs (regarding the EH-chain length) at transit routers" 
is probably inappropriate.

That said, if you have any suggested tweaks, please do let us know (I'm 
all for improving the document).

> 2 - First bullet point in Section 2.3, change
> "recognise" to "recognize" 3

Will do.

> - Within the last paragraph of section
> 2.3, part of the comment ".... it is generally desirable that the
> sender be signaled of the packet drop...." While the idea is valid,
> it might be a good idea to note that such a signal might attract
> malicious attention or threat-actors.

You mean "expose the filtering policy"? If not, please elaborate. :-)

> 4 - Section 3.4.4.4. It might
> be best to specify what type of IPSEC deployment is involved,
> host-to-host, site-to-site, site-to-host? 

Could you please elaborate a bit on this one?

> 5 - Section 3.4.5.5.
> Advise, hasn't AH been depreciated as an insecure methodology versus
> ESP?

That'd generally be my take. But AH has never been formally obsoleted. 
While double-checking this, I ended up finding this thread 
(http://www.sandelman.ottawa.on.ca/ipsec/2000/06/threads.html#00063 ) in 
which some folks have actually suggested that, but it looks like the 
idea didn't fly.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Michael Dougherty <[email-masked]>
Date: Sun, 24 Jan 2021 14:16:24 +0000

Hello Fernando,

Thanks for the reply, I wasn’t sure if you received my message, but I am glad that it has helped. I reviewed your comments and responded to them below. I am happy to help out.

-michael

On 1/24/21, 12:45 AM, "Fernando Gont" <[email-masked]> wrote:

    Hello, Michael,

//MD Reply - 24JAN2021 \\

The use of the semi-colon would be a good fit here, since the two sections are related but are separate sentence clauses - technically it would work. Take a look at my rewrite below, hopefully it still conveys the idea. 

Possible rewrite: While some operators "officially" drop packets containing IPv6 EHs, inappropriate defaults or incorrect advice in this area may result in the recording of elevated drops.

    Will do!

    Will do.

MD: I reviewed the RFC7872 and you could maybe rephrase to include the call out of 7872, but also cover anything that might be considered.

/// The advice conveyed in this document is to assist network operators with developing or refining packet dropping policies for IPv6 EH entering or leaving their operational responsibilities. Guidelines contained in RFC7872 may not have information for specific use cases or situations; this document may positively affect updated policies.  \\\

    Will do.

MD Response: Yes, that is exactly what I am referencing. Sending back an ICMP error message to the originating host may expose the "reporting devices" existence or operation. 

MD Response: It was more so a comment regarding how specific you want to be with the possibly breaking IPSec deployments. In general, yes, calling out as you have would cover various deployments or operational considerations. Being this document is aimed towards transit and possibly applicable to IXP's, they may not be mindful of how end-users might be operating. 

MD Response: It seems you are correct, at a standards level AH appears to be not be officially depreciated. While it sounds like there is discussion and need to do so, it has not been done. I will say some vendors do recommend ESP over AH, such as Juniper in their 2012 document, "Concepts & Examples ScreenOS Reference Guide Virtual Private Networks." Regardless, you can probably ignore my previous comment. 

    Thanks!

    Regards,