> On Nov 9, 2019, at 3:54 PM, Bob Hinden <[email protected]> wrote: > > Gyan, > >> On Nov 9, 2019, at 12:09 PM, Gyan Mishra <[email protected]> wrote: >> >> >> >> >>> On Nov 9, 2019, at 11:46 AM, Bob Hinden <[email protected]> wrote: >>> >>> Eric, >>> >>>> On Nov 8, 2019, at 11:57 PM, Eric Vyncke (evyncke) <[email protected]> >>>> wrote: >>>> >>>> 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. >>> >>> 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. >>> >>> [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. > > 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 > Understood. How about “forward” or “redirect”.
> >>> >>> >>> >>> >>> >>>> >>>> Regards >>>> >>>> -éric >>>> >>>> From: Gyan Mishra <[email protected]> >>>> Date: Saturday, 9 November 2019 at 08:28 >>>> To: Eric Vyncke <[email protected]> >>>> Cc: "[email protected]" <[email protected]>, "[email protected]" >>>> <[email protected]> >>>> Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-21.txt >>>> >>>> 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 protected]> >>>>> wrote: >>>>> 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 protected]> wrote: >>>>> >>>>> 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 protected] wrote: >>>>>> >>>>>> >>>>>> 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/ >>>>>> >>>>>> _______________________________________________ >>>>>> OPSEC mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/opsec >>>>> >>>>> >>>> >>>> >>>> -- >>>> 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 protected] >>>> www.linkedin.com/in/networking-technologies-consultant >>>> >>>> _______________________________________________ >>>> OPSEC mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/opsec >>> > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
