Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt

From: [email-masked]
Date: Sun, 03 Nov 2019 13:56:44 -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           : Operational Security Considerations for IPv6 Networks
        Authors         : Eric Vyncke
                          Kiran Kumar Chittimaneni
                          Merike Kaeo
                          Enno Rey
	Filename        : draft-ietf-opsec-v6-21.txt
	Pages           : 52
	Date            : 2019-11-03

Abstract:
   Knowledge and experience on how to operate IPv4 securely is
   available: whether it is the Internet or an enterprise internal
   network.  However, IPv6 presents some new security challenges.  RFC
   4942 describes the security issues in the protocol but network
   managers also need a more practical, operations-minded document to
   enumerate advantages and/or disadvantages of certain choices.

   This document analyzes the operational security issues in several
   places of a network (enterprises, service providers and residential
   users) and proposes technical and procedural mitigations techniques.
   Some very specific places of a network such as the Internet of Things
   are not discussed in this document.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsec-v6-21
https://datatracker.ietf.org/doc/html/draft-ietf-opsec-v6-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-21

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: Gyan Mishra <[email-masked]>
Date: Mon, 4 Nov 2019 09:25:58 -0500

Hi Eric 

Just checking what the updates are that went in v21 since this document is now ready to be published just pending my Shepard writeup which I plan to finish this week.  

Thank you 

Gyan

Sent from my iPhone

> On Nov 3, 2019, at 4:56 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 4 Nov 2019 14:38:04 +0000

Hello Gyan,

Thank you for reminding the author to post the 'gist' of the changes with version -21.

Our OPS AD, Warren "Ace" Kumari,  has kindly reviewed our document and has identified more than 70 areas where the text was ambiguous or using bad English... No wonder, none of the 4 authors are English-speaking native: it is a mix of Estonian (Merike who also speaks German and Russian[1]), one of the 22 (?) language of India (KK), German (Enno who also speaks French and Spanish) and French (myself also speaking Dutch) __ __ IETF community is really diverse !

Thank you very much in advance for finalizing the shepherd write-up

-éric

[1] I can be wrong for Merike BTW but she is quadri-lingual

On 04/11/2019, 15:26, "Gyan Mishra" <[email-masked]> wrote:

    Hi Eric 

    Thank you 
    
    Gyan
    
    Sent from my iPhone

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 9 Nov 2019 02:27:29 -0500

Eric

I submitted the shepherd write-up.

I ran the idnits and it found the following obsolete references.  We should
clear that up before we publish it.  I can update my comments on that once
the draft is updated.

Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  -- Obsolete informational reference (is this intentional?): RFC 2460
     (Obsoleted by RFC 8200)

  -- Obsolete informational reference (is this intentional?): RFC 3068
     (Obsoleted by RFC 7526)

  -- Obsolete informational reference (is this intentional?): RFC 3627
     (Obsoleted by RFC 6547)

Thank you

Gyan

On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) <[email-masked]>
wrote:

> Our OPS AD, Warren "Ace" Kumari,  has kindly reviewed our document and has
> identified more than 70 areas where the text was ambiguous or using bad
> English... No wonder, none of the 4 authors are English-speaking native: it
> is a mix of Estonian (Merike who also speaks German and Russian[1]), one of
> the 22 (?) language of India (KK), German (Enno who also speaks French and
> Spanish) and French (myself also speaking Dutch) __ __ IETF community is
> really diverse !
>
>     Just checking what the updates are that went in v21 since this
> document is now ready to be published just pending my Shepard writeup which
> I plan to finish this week.
>
>     Thank you
>
>     Gyan
>
>     Sent from my iPhone
>
>     > This draft is a work item of the Operational Security Capabilities
> for IP Network Infrastructure WG of the IETF.
>     >

-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 9 Nov 2019 07:57:26 +0000

Gyan

Thank you very much for your shepherd write-up, very much appreciated by the authors.

The list of the ‘obsoleted’ references is intentional indeed to ensure that readers understand that ‘old’ documents have been replaced. The text in the document is clear about the obsolete and current document. So, we do prefer to leave the references like they are as we believe that they make the document more valuable for the reader.

Regards

-éric

From: Gyan Mishra <[email-masked]>
Date: Saturday, 9 November 2019 at 08:28
To: Eric Vyncke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt

Eric

I ran the idnits and it found the following obsolete references.  We should clear that up before we publish it.  I can update my comments on that once the draft is updated.

     (Obsoleted by RFC 8200)

     (Obsoleted by RFC 7526)

     (Obsoleted by RFC 6547)

Thank you

Gyan

On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Gyan,

-éric

On 04/11/2019, 15:26, "Gyan Mishra" <[email-masked]<mailto:[email-masked]>> wrote:

    Hi Eric

    Thank you

    Gyan

    Sent from my iPhone

    > On Nov 3, 2019, at 4:56 PM, [email-masked]<mailto:[email-masked]> wrote:
    >
    >
    > until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
    >
    > [email-masked]<mailto:[email-masked]>

--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia Pike FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-1347
Email: [email-masked]<mailto:[email-masked]>
www.linkedin.com/in/networking-technologies-consultant<http://www.linkedin.com/in/networking-technologies-consultant>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 9 Nov 2019 08:46:32 -0800

Eric,

> On Nov 8, 2019, at 11:57 PM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> Gyan
> 

I went back and reread this.  The text:

   2.2.2.  Hop-by-Hop Options Header

   The hop-by-hop options header, when present in an IPv6 packet, forces
   all nodes in the path to inspect this header in the original IPv6
   specification [RFC2460].  This enables denial of service attacks as
   most, if not all, routers cannot process this kind of packets in
   hardware but have to 'punt' this packet for software processing.
   Section 4.3 of the current Internet Standard for IPv6, [RFC8200], has
   taken this attack vector into account and made the processing of hop-
   by-hop options header by intermediate routers optional.

I don’t understand why this is talking about RFC2460 at all.  Seems like it would less confusing to only describe what is in RFC8200.  Nor is “punt” correct way to describe this.   Way too colloquial.

Describing RFC8200 behavior as “optional" is quite right, RFC8200 says:

   ...now expected that nodes along a packet's delivery path only examine and process the
      Hop-by-Hop Options header if explicitly configured to do so

It’s not optional if configured to do so.  It would be better to use the RFC8200 words.

Lastly the “Original" IPv6 Specification was RFC1883.

Bob

p.s. I agree about the references to RFC 3068 and RFC 3627.

> On Mon, Nov 4, 2019 at 9:38 AM Eric Vyncke (evyncke) <[email-masked]> wrote:
>> Hello Gyan,
>>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 9 Nov 2019 14:42:59 -0500

Most welcome Eric!

I will update the write-up based on what you stated on the intended obsoleted references.

Gyan

Sent from my iPhone

> On Nov 9, 2019, at 2:57 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> Gyan
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 9 Nov 2019 15:09:57 -0500

> On Nov 9, 2019, at 11:46 AM, Bob Hinden <[email-masked]> wrote:
> 
> Eric,
> 
> [Gyan] I agree with Bob about RFC 8200 as it’s a major update to the original IPv6 specification written in 1998 by Bob as well.  The other two are minor and agree to the historical deprecated informational references.

The term “punt to cpu” is commonly used by router vendors when switching from the slow software switched path which hits the RP CPU versus the hardware switched fast path which remains on the line card NP processor.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 9 Nov 2019 12:54:01 -0800

Gyan,

> On Nov 9, 2019, at 12:09 PM, Gyan Mishra <[email-masked]> wrote:
> 
> 
> 
> 

I understand what it means, but as I said its colloquial and may not be clear to some readers.  Not appropriate for a document like this, IMHO.

Bob

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 9 Nov 2019 16:08:13 -0500

> On Nov 9, 2019, at 3:54 PM, Bob Hinden <[email-masked]> wrote:
> 
> Gyan,
> 
Understood. How about “forward” or “redirect”.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 9 Nov 2019 13:34:45 -0800

Gyan,

> On Nov 9, 2019, at 1:08 PM, Gyan Mishra <[email-masked]> wrote:
> 
> 
> 

That’s better.

Thanks,
Bob

---

From: Ole Troan <[email-masked]>
Date: Sat, 9 Nov 2019 22:49:26 +0100

> On 9 Nov 2019, at 22:35, Bob Hinden <[email-masked]> wrote:
> 

I believe this statement is far out of date. 
I would recommend getting recent data on this or delete it. 

Cheers 
Ole

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 9 Nov 2019 21:15:59 -0500

> On Nov 9, 2019, at 4:49 PM, Ole Troan <[email-masked]> wrote:
> 
> 
> 

This draft expired late 2016 so only few years old on this subject.

https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03

So I think the main issue with hbh is that even on  the latest modern high end routers that process everything in hardware in the forwarding plane that hbh processing had to be sent to the control plane because some hbh options are used in the forwarding plane like jumbo frames, while others are to be consumed by the control plane such as router alert.  Older routers forwarded all hbh from the forwarding plane to the control plane which now newer routers don’t do so but you still have hbh options that have to be consumed by the control plane.

Excerpt from the draft above.

Many modern routers maintain a strict separation between forwarding plane hardware and control plane hardware. In these routers, forwarding plane bandwidth is plentiful, while control plane bandwidth is constrained. In order to protect scarce control plane resources, these routers enforce policies the restrict access from the from the forwarding plane to the control plane. Effective policies address packets containing the HBH Options Extension header, because HBH control options require access from the forwarding plane to the control plane. Many network operators perceive HBH Options to be a breach of the separation between the forwarding and control planes [I-D.ietf-v6ops-ipv6-ehs-in-real-world]. Therefore, some network operators discard all packets containing the HBH Options Extension Header, while others forward the packets but ignore the HBH Options.    Still other operators severely rate-limit packets containing the HBH Options Extension Header. In addition, some (notably older) implementations send all packets containing a HBH header to the control plane even if they contain only pad options, resulting in an effect DoS on the router and inconsistent drops among those packets due to rate limiting or other factors. [RFC7045] legitimizes the current state of affairs, severely limiting the utility of HBH options. In the words of RFC 7045: "The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in RFC2460. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing       path. Designers planning to use a Hop-by-Hop option need to be aware of this likely behaviour."

https://tools.ietf.org/html/rfc7045

2.2. Hop-by-Hop Options The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes as described in [RFC2460]. However, it is to be expected that high-performance routers will either ignore it or assign packets containing it to a slow processing path. Designers planning to use a hop-by-hop option need to be aware of this likely behaviour. As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options header, if present, must be first.

We should reference these two documents in this draft which I have to check.

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 10 Nov 2019 11:38:14 -0500

> On Nov 9, 2019, at 9:15 PM, Gyan Mishra <[email-masked]> wrote:
> 
> 
> 
> 
> 

Ole

Thanks for the comments.  I think the hbh section is most pertinent to this I-D.  I will work with the authors to update with current data.

Gyan

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 12 Nov 2019 11:03:13 +0000

Bob

Thank you for reading our document.

I will keep the reference to RFC 2460 simply because the vast majority, IMHO, of deployed devices still follow this RFC and not 8200. (BTW, we will fix the "original" part). 

'punt' is indeed a Cisco-language, so, let's also change it.

Finally, we will extend/clarify the 'optional' part of HbB in RFC 8200 that was oversimplification.

=> all the above will be updated when the IETF-wide LastCall is over.

Regards

-éric

On 09/11/2019, 17:47, "Bob Hinden" <[email-masked]> wrote:

    Eric,

    

    

    
    
    Bob