Gyan, > On Nov 9, 2019, at 1:08 PM, Gyan Mishra <[email protected]> wrote: > > > >> 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”.
That’s better. Thanks, 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
