Hi All, I am very much interested to contribute towards BGP EVPN. Has the development started?
Thanks, Purushoth On Wed, Nov 16, 2016 at 5:30 PM, <quagga-dev-requ...@lists.quagga.net> wrote: > Send Quagga-dev mailing list submissions to > quagga-dev@lists.quagga.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.quagga.net/mailman/listinfo/quagga-dev > > You can reach the person managing the list at > quagga-dev-ow...@lists.quagga.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Quagga-dev digest..." > > > Today's Topics: > > 1. [quagga-dev 16401] Re [PATCH 00/57] Ethernet VPN RFC Patch > (Jason Higgins) > 2. [quagga-dev 16402] Re: [quagga-users 14444] Quagga CVE > Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) > (Martin Winter) > 3. [quagga-dev 16403] Thursday lunch meet up @ietf (Lou Berger) > 4. [quagga-dev 16404] Re: Thursday lunch meet up @ietf (David Bond) > 5. [quagga-dev 16405] Re: [quagga-users 14521] Quagga CVE > Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) > (Alexis Rosen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 15 Nov 2016 19:43:14 +0000 > From: Jason Higgins <jason.higg...@spark.co.nz> > To: "quagga-dev@lists.quagga.net" <quagga-dev@lists.quagga.net> > Subject: [quagga-dev 16401] Re [PATCH 00/57] Ethernet VPN RFC Patch > Message-ID: > <SYXPR01MB187250CEA6F5B8A0707ADF5BBBBF0@SYXPR01MB1872. > ausprd01.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > I have noticed that support for EVPN is underway for Quagga. > https://lists.quagga.net/pipermail/quagga-dev/2016-October/016421.html > > > When can we expect it to be integrated into Quagga? > I would love to be able to use it, as soon as possible. > There is definitely benefits beyond the scope of DC environments too. > > > Thank you for all the hard work. It is great to see how far Quagga has > come. > > > Let me know if you would like any help with testing as well. > > > Kind Regards > ________________________________ > [spark] > > > > Jason Higgins > Network and Solution Designer > Spark Platforms > T > > +64 3 353 5335 (extn 32335) > > M > > +64 27 539 0307 > > E > > jason.higg...@spark.co.nz > > Level 1, 16 Walker Street > P O Box 1473, Christchurch 8140 > www.spark.co.nz<http://www.spark.co.nz> > > ________________________________ > > This communication, including any attachments, is confidential. If you are > not the intended recipient, you should not read it - please contact me > immediately, destroy it, and do not copy or use any part of this > communication or disclose anything about it. Thank you. Please note that > this communication does not designate an information system for the > purposes of the Electronic Transactions Act 2002. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.quagga.net/pipermail/quagga-dev/ > attachments/20161115/5542d88c/attachment-0001.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.png > Type: image/png > Size: 20987 bytes > Desc: image001.png > URL: <http://lists.quagga.net/pipermail/quagga-dev/ > attachments/20161115/5542d88c/attachment-0002.png> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image002.png > Type: image/png > Size: 167 bytes > Desc: image002.png > URL: <http://lists.quagga.net/pipermail/quagga-dev/ > attachments/20161115/5542d88c/attachment-0003.png> > > ------------------------------ > > Message: 2 > Date: Tue, 15 Nov 2016 15:00:04 -0800 > From: "Martin Winter" <mwin...@opensourcerouting.org> > To: "Alexis Rosen" <quagga-us...@alexis.users.panix.com> > Cc: Quagga Users Lists <quagga-us...@lists.quagga.net>, Quagga > development list <quagga-dev@lists.quagga.net> > Subject: [quagga-dev 16402] Re: [quagga-users 14444] Quagga CVE > Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) > Message-ID: > <d9a2b9ce-00a5-488d-987e-daf921867...@opensourcerouting.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > > > On 14 Nov 2016, at 21:20, Alexis Rosen wrote: > > > On Oct 18, 2016, at 1:56 AM, Martin Winter > > <mwin...@opensourcerouting.org> wrote: > >> Security Advisory: Quagga Buffer Overflow in IPv6 RA handling > >> ============================================================= > >> > >> [...] The issue can be triggered on an IPv6 address where the Quagga > >> daemon is reachable by a RA (Router Advertisement or IPv6 ICMP > >> message. > > > > So... Nearly a month later, I'm deleting old mail and noticed this. > > > > As far as I can tell, this is an editing error of some sort, and in > > fact you can NOT trigger the issue simply by having an IPv6 address > > reachable with an ICMP. > > How about this wording: > > A buffer overflow exists in the IPv6 (Router Advertisement) code in > Zebra. The issue can be triggered on any interface with a reachable > IPv6 address > by a RA (Router Advertisement) or IPv6 ICMP message. > The issue leads to a crash of the zebra daemon. > > > Later in the advisory, it says: > >> Usage of Quagga without running the 'zebra' daemon, or no > >> IPv6 neighbor-discovery are not affected. > > What this should say: > The issue is in Zebra daemon. So you are safe without Zebra daemon (i.e. > some users only using BGPd) > You are also safe if you have the IPv6 neighbor-discovery disabled. > > So maybe just a missing comma? > > Usage of Quagga without running the 'zebra' daemon, or no > IPv6 neighbor-discovery, are not affected. > > > A quick look at the code also suggests this is so, but my familiarity > > with this code is basically nil, and it would be very easy for me to > > get this wrong. > > > > Can someone who is certain please clarify? And maybe update the CVE so > > the sentence makes sense (and has balanced parentheses)? > > I?ll update if you can confirm that these 2 small rewrites clarify the > issue. > > - Martin > > > > ------------------------------ > > Message: 3 > Date: Wed, 16 Nov 2016 12:49:19 +0900 > From: Lou Berger <lber...@labn.net> > To: <quagga-dev@lists.quagga.net> > Subject: [quagga-dev 16403] Thursday lunch meet up @ietf > Message-ID: > <1586b40ce18.2818.9b4188e636579690ba6c69f2c8a0f...@labn.net> > Content-Type: text/plain; format=flowed; charset="us-ascii" > > Anyone interested? We can meet up at ietf reception, near park ballroom > 2.... > > > > > > ------------------------------ > > Message: 4 > Date: Wed, 16 Nov 2016 13:06:05 +0900 > From: David Bond <db...@128technology.com> > To: Lou Berger <lber...@labn.net> > Cc: quagga-dev@lists.quagga.net > Subject: [quagga-dev 16404] Re: Thursday lunch meet up @ietf > Message-ID: > <CABRjVhencUyJD5aUym=ELYy0ULV6bKhJFp+m69UxFcEeAk5_Ow@mail. > gmail.com> > Content-Type: text/plain; charset="utf-8" > > I would but I have a prior engagement at that time. > David > > On Nov 16, 2016 12:51 PM, "Lou Berger" <lber...@labn.net> wrote: > > > Anyone interested? We can meet up at ietf reception, near park ballroom > > 2.... > > > > > > > > _______________________________________________ > > Quagga-dev mailing list > > Quagga-dev@lists.quagga.net > > https://lists.quagga.net/mailman/listinfo/quagga-dev > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.quagga.net/pipermail/quagga-dev/ > attachments/20161116/d172858f/attachment-0001.html> > > ------------------------------ > > Message: 5 > Date: Wed, 16 Nov 2016 04:38:01 -0500 > From: Alexis Rosen <quagga-us...@alexis.users.panix.com> > To: Martin Winter <mwin...@opensourcerouting.org> > Cc: Quagga Users Lists <quagga-us...@lists.quagga.net>, Quagga > development list <quagga-dev@lists.quagga.net> > Subject: [quagga-dev 16405] Re: [quagga-users 14521] Quagga CVE > Released: CVE-2016-1245 (Fix in latest 1.0.20161017 release) > Message-ID: > <fa296cef-ad29-4eb7-b14b-3bbad5bbb...@alexis.users.panix.com> > Content-Type: text/plain; charset=us-ascii > > While I was at first concerned about wording, which I address first, I am > also concerned about the substance of the CVE, which I'll address at the > end. > > On Nov 15, 2016, at 6:00 PM, Martin Winter <mwin...@opensourcerouting.org> > wrote: > > On 14 Nov 2016, at 21:20, Alexis Rosen wrote: > >> On Oct 18, 2016, at 1:56 AM, Martin Winter < > mwin...@opensourcerouting.org> wrote: > >>> Security Advisory: Quagga Buffer Overflow in IPv6 RA handling > >>> ============================================================= > >>> > >>> [...] The issue can be triggered on an IPv6 address where the Quagga > >>> daemon is reachable by a RA (Router Advertisement or IPv6 ICMP message. > >> > >> So... Nearly a month later, I'm deleting old mail and noticed this. > >> > >> As far as I can tell, this is an editing error of some sort, and in > fact you can NOT trigger the issue simply by having an IPv6 address > reachable with an ICMP. > > > > How about this wording: > > > > A buffer overflow exists in the IPv6 (Router Advertisement) code in > > Zebra. The issue can be triggered on any interface with a > reachable IPv6 address > > by a RA (Router Advertisement) or IPv6 ICMP message. > > The issue leads to a crash of the zebra daemon. > > Actually, this continues the confusion. The statement above is compatible > with this interpretation: > The issue can be triggered on any interface with a reachable IPv6 > address > by any IPv6 ICMP message > > ...but that's not true. I think what you're trying to say is this: > The issue can be triggered on any interface that has a reachable > IPv6 address > by a Router Advertisement packet ("RA", or ICMPv6 type 134). > > Also, there is ambiguity as to whether RA-issuing or RA-receiving code is > the problem (see below). > > If I am correct, then let me suggest the following as a complete > replacement for the lead paragraph: > > A remotely exploitable buffer overflow exists in the IPv6 Router > Advertisement reception code in Zebra. The issue can be triggered > on any interface that has a reachable IPv6 address, by a Router > Advertisement packet ("RA", or ICMPv6 type 134). To be vulnerable, > the Zebra daemon must be running, and the non-default "no ipv6 nd > suppress-ra" must be enabled an at least one interface. > > >> Later in the advisory, it says: > >>> Usage of Quagga without running the 'zebra' daemon, or no > >>> IPv6 neighbor-discovery are not affected. > > > > What this should say: > > The issue is in Zebra daemon. So you are safe without Zebra daemon (i.e. > some users only using BGPd) > > You are also safe if you have the IPv6 neighbor-discovery disabled. > > > > So maybe just a missing comma? > > > > Usage of Quagga without running the 'zebra' daemon, or no > > IPv6 neighbor-discovery, are not affected. > > That's ambiguous because of the double-negative. > > Maybe this? > Users of Quagga who do not use the Zebra daemon are NOT affected. > Users of Zebra who have IPv6 neighbor-discovery disabled (the > default) are NOT affected. Enabling IPv6 neighbor-discovery on > ANY interface exposes users to this attack on EVERY IPv6 interface. > > > However I am still puzzled by something. "ipv6 nd suppress-ra" prevents > Quagga from *sending* RAs. But the bug described is in receiving RAs. Will > "ipv6 nd suppress-ra" really prevent the bug? > > Since this bug only affects Linux, would it instead make more sense to do > net.ipv6.conf.all.accept_ra=0 > and maybe > net.ipv6.conf.default.accept_ra=0 > instead to work around the bug? That would prevent processing of all RA > messages on every interface. Another approach would be to turn off > autoconfig for all interfaces, but I am not 100% sure the vulnerable code > path would be avoided then. > > > Thanks, and sorry this is so late. > > /a > > > ------------------------------ > > _______________________________________________ > Quagga-dev mailing list > Quagga-dev@lists.quagga.net > https://lists.quagga.net/mailman/listinfo/quagga-dev > > End of Quagga-dev Digest, Vol 160, Issue 6 > ****************************************** >
_______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev