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 >> >> >> >> >> >>> >>> 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 >>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
