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-request@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-owner@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.Higgins@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.Higgins@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" <mwinter@opensourcerouting.org>
> To: "Alexis Rosen" <quagga-users@alexis.users.panix.com>
> Cc: Quagga Users Lists <quagga-users@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-DAF921867F83@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
> > <mwinter@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 <lberger@labn.net>
> To: <quagga-dev@lists.quagga.net>
> Subject: [quagga-dev 16403] Thursday lunch meet up @ietf
> Message-ID:
> <1586b40ce18.2818.9b4188e636579690ba6c69f2c8a0f1fd@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 <dbond@128technology.com>
> To: Lou Berger <lberger@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" <lberger@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-users@alexis.users.panix.com>
> To: Martin Winter <mwinter@opensourcerouting.org>
> Cc: Quagga Users Lists <quagga-users@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-3BBAD5BBB301@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 <mwinter@opensourcerouting.org>
> wrote:
> > On 14 Nov 2016, at 21:20, Alexis Rosen wrote:
> >> On Oct 18, 2016, at 1:56 AM, Martin Winter <
> mwinter@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
> ******************************************
>
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-request@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-owner@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.Higgins@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.Higgins@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" <mwinter@opensourcerouting.org>
> To: "Alexis Rosen" <quagga-users@alexis.users.panix.com>
> Cc: Quagga Users Lists <quagga-users@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-DAF921867F83@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
> > <mwinter@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 <lberger@labn.net>
> To: <quagga-dev@lists.quagga.net>
> Subject: [quagga-dev 16403] Thursday lunch meet up @ietf
> Message-ID:
> <1586b40ce18.2818.9b4188e636579690ba6c69f2c8a0f1fd@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 <dbond@128technology.com>
> To: Lou Berger <lberger@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" <lberger@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-users@alexis.users.panix.com>
> To: Martin Winter <mwinter@opensourcerouting.org>
> Cc: Quagga Users Lists <quagga-users@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-3BBAD5BBB301@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 <mwinter@opensourcerouting.org>
> wrote:
> > On 14 Nov 2016, at 21:20, Alexis Rosen wrote:
> >> On Oct 18, 2016, at 1:56 AM, Martin Winter <
> mwinter@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
> ******************************************
>