http://permalink.gmane.org/gmane.network.quagga.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.network.quagga.devel/10583 <pre> Unfortunately, I didn't have time yet to look at this in detail. However I feel that having decent RPKI support would definitively be a good thing and something that should make it into mainline. -Christian </pre> Christian Franke 2013-06-17T21:24:55 http://permalink.gmane.org/gmane.network.quagga.devel/10582 <pre>11.06.2013, 12:57, "Lokesh Pareta" &lt;lokesh.pareta&lt; at &gt;tcs.com&gt;: Hi Lokesh. Your concern above is very clear, but some things are beyond my responsibility. That is, everyone is in their right to decide whether their version of Quagga includes or not the works I (or anybody else) occasionally contribute. As a subscriber to this mailing list I can share some expertise on authentication and/or the source code I have authored, but for the rest you would have to make your own judgement. All that said, I really appreciate your will to implement modern specifications and contribute back to Free Software. No doubt I may be wrong here, but then the code shouldn't allow for two execution branches: + if (list_isempty (oi-&gt;auth_crypt)) + auth_key = (const u_int8_t *) ""; + else + { + ck = listgetdata (listtail(oi-&gt;auth_crypt)); + auth_key = ck-&gt;auth_key; + } </pre> Denis Ovsienko 2013-06-17T19:31:54 http://permalink.gmane.org/gmane.network.quagga.devel/10581 <pre>Hi Greg, On Mon, 17 Jun 2013, Greg Troxel wrote: our extension is wholly separate from BGPSRx. It does not use BGPSRx. OK, so far we tested under Linux x86-64. Thanks matthias </pre> Matthias Waehlisch 2013-06-17T17:32:40 http://permalink.gmane.org/gmane.network.quagga.devel/10580 <pre> Matthias Waehlisch &lt;waehlisch&lt; at &gt;ieee.org&gt; writes: (narrowing to -dev) What do you mean by "in addition to BGPSRx"? Is this wholly spearate? Or does one use that, and then your code on top of it? This mentions "run ldconfig", which feels linux-specific. It would be good to list the OS and CPU combinations your code is known to build/run on. </pre> Greg Troxel 2013-06-17T17:27:11 http://permalink.gmane.org/gmane.network.quagga.devel/10579 <pre>Hi Quagga folks, we currently work on an RPKI extension for Quagga. It implements prefix origin validation. This project is in addition to BGPSRx. Our implementation uses the RTRlib, which is RFC 6810 and RFC 6811 compliant. For prefix origin validation, only a connection to an operating RTR cache server is required. The current state is beta. Feel free to have a look. Git Repository git://github.com/rtrlib/quagga-rtrlib.git Installation instructions http://rpki.realmv6.org/wiki/QuaggaExtensionInstallation User manual http://rpki.realmv6.org/raw-attachment/wiki/Documentation/QuaggaRTRlibManual.pdf Any comments would be highly appreciated. In particular we would like to know if there is enough interest to integrate this feature into the master branch once the extension is stable. Thanks matthias </pre> Matthias Waehlisch 2013-06-17T10:25:14 http://permalink.gmane.org/gmane.network.quagga.devel/10578 <pre>please ignore. </pre> Matthias Waehlisch 2013-06-17T14:51:01 http://permalink.gmane.org/gmane.network.quagga.devel/10577 <pre>Hi Quagga folks, we currently work on an RPKI extension for Quagga. It implements prefix origin validation. This project is in addition to BGPSRx. Our implementation uses the RTRlib, which is RFC 6810 and RFC 6811 compliant. For prefix origin validation, only a connection to an operating RTR cache server is required. The current state is beta. Feel free to have a look. Git Repository git://github.com/rtrlib/quagga-rtrlib.git Installation instructions http://rpki.realmv6.org/wiki/QuaggaExtensionInstallation User manual http://rpki.realmv6.org/raw-attachment/wiki/Documentation/QuaggaRTRlibManual.pdf Any comments would be highly appreciated. In particular we would like to know if there is enough interest to integrate this feature into the master branch once the extension is stable. Thanks matthias </pre> Matthias Waehlisch 2013-06-15T13:58:54 http://permalink.gmane.org/gmane.network.quagga.devel/10576 <pre>Hi Denis, Thanks for your suggestions and feedback. Please refer to the below mail and respond to queries so that TCS can proceed with RFC-6506 quagga implementations. Thanks and Regards, Saloni Jain Tata Consultancy Services Mailto: saloni.jain&lt; at &gt;tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ From: Lokesh Pareta/DEL/TCS To: infrastation&lt; at &gt;yandex.ru Cc: quagga-dev&lt; at &gt;lists.quagga.net, Rajeev Agarwal/DEL/TCS&lt; at &gt;TCS, Deepankar Gupta/DEL/TCS&lt; at &gt;TCS, Saloni Jain/DEL/TCS&lt; at &gt;TCS Date: 06/11/2013 12:27 PM Subject: Re: [quagga-dev 10527] RFC-6506(Supporting Authentication Trailer for OSPFv3) implementation in quagga-0.99.21 version Hi Denis, Thanks for you feedback. In response to your suggestion, we require more inputs on following points: "It is possible to see that these prior works establish and use a common internal API to</pre> Saloni Jain 2013-06-17T10:40:30 http://permalink.gmane.org/gmane.network.quagga.devel/10575 <pre>Hi, When we change the router-id in OSPF the routing table doesn't get updated, i.e the routes learned from neighbors will be lost. Should we restart the OSPF process once the router-id is changed ? Or do we have any command like Cisco's "clear ip ospf process" to reset the process once the router-id is changed. Thank You, Mahant Software Engineer Bangalore </pre> Mahant 2013-06-13T06:55:32 http://permalink.gmane.org/gmane.network.quagga.devel/10574 <pre>For all that are interested in NIST's RPKI prefix/origin validation reference implementation for Quagga (BGPSRx / QuaggaSRx), we merged the code from Quagga 0.99.16 to be based on Quagga 0.99.22. The code is available at http://www-x.antd.nist.gov/bgpsrx For questions or comments don't hesitate to contact us at bgpsrx-dev&lt; at &gt;nist.gov&lt;mailto:bgpsrx-dev&lt; at &gt;nist.gov&gt; Thanks, Oliver ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238 </pre> Borchert, Oliver 2013-06-11T16:46:17 http://permalink.gmane.org/gmane.network.quagga.devel/10573 <pre> Hi Denis, Thanks for you feedback. In response to your suggestion, we require more inputs on following points:  " It is possible to see that these prior works establish and use a common internal API to cryptographic hash algorithms implemented in a library, libgcrypt in this case. This approach provides agility without the cost of duplicating and maintaining the source code of each hash algorithm in use. Agility matters within the scope of this work, because RFC6506 sets SHA-256 as the mandatory-to-implement, but not the only possible hash algorithm. The contents of sha256.c and sha256.h together with much of the code in ospf6_check_sha256_digest() and ospf6_make_sha256_digest(), which implement the construct specified in RFC6506 (and derived from RFC4822), can be replaced with a call to hash_key_compress_rfc4822() and hash_make_hmac()."  TCS inference -  The functions hash_key_compress_rfc4822() and hash_make_hmac() are present in the code downloaded from the link as suggested , but were </pre> Lokesh Pareta 2013-06-11T06:57:19 http://permalink.gmane.org/gmane.network.quagga.devel/10572 <pre>09.05.2013, 09:46, "Lokesh Pareta" &lt;lokesh.pareta&lt; at &gt;tcs.com&gt;: [...] Hello, Lokesh. Below is a cursory review of the patch, which the author of this work may use to improve it further. RFC6506 belongs to a series of works on routing protocols authentication using cryptographic hash algorithms. My personal experience in implementing such authentication in Quagga code base stands for: * implementation of RIPv2 authentication (http://tools.ietf.org/html/rfc4822), annotated in detail in http://marc.info/?l=quagga-dev&amp;m=135244834410653 * design and implementation of Babel authentication (http://tools.ietf.org/html/draft-ovsienko-babel-hmac-authentication) The commits standing for these two works are mapped here: https://github.com/Quagga-RE/quagga-RE/wiki/hashes It is possible to see that these prior works establish and use a common internal API to cryptographic hash algorithms implemented in a library, libgcrypt in this case. This approach provides agility without the cost of duplicating and maintaining the so</pre> Denis Ovsienko 2013-05-29T08:25:30 http://permalink.gmane.org/gmane.network.quagga.devel/10571 <pre>Since commit ba281d3d040, ospfd uses NEXTHOP_IPV4_IFINDEX routes. The API between zebra and bgpd which is used to query nexthops for recursive routes did not support this nexthop type and therefore, ospf changes (or any other IGP changes which use NEXTHOP_IPV4_IFINDEX) would never trigger any recursive route update. Signed-off-by: Christian Franke &lt;chris&lt; at &gt;opensourcerouting.org&gt; --- bgpd/bgp_nexthop.c | 13 +++++++++++++ zebra/zserv.c | 12 ++++++++++++ 2 files changed, 25 insertions(+) diff --git a/bgpd/bgp_nexthop.c b/bgpd/bgp_nexthop.c index d469236..69440ce 100644 --- a/bgpd/bgp_nexthop.c +++ b/bgpd/bgp_nexthop.c &lt; at &gt;&lt; at &gt; -122,6 +122,11 &lt; at &gt;&lt; at &gt; bgp_nexthop_same (struct nexthop *next1, struct nexthop *next2) if (! IPV4_ADDR_SAME (&amp;next1-&gt;gate.ipv4, &amp;next2-&gt;gate.ipv4)) return 0; break; + case ZEBRA_NEXTHOP_IPV4_IFINDEX: + if (! IPV4_ADDR_SAME (&amp;next1-&gt;gate.ipv4, &amp;next2-&gt;gate.ipv4) + || next1-&gt;ifindex != next2-&gt;ifindex) +return 0; + break; case ZEBRA_NEXTHOP_IFINDEX: </pre> Christian Franke 2013-05-25T15:01:35 http://permalink.gmane.org/gmane.network.quagga.devel/10570 <pre>Commit ba281d3d04 and its previous commit added support for NEXTHOP_IPV4_IFINDEX and make use of it for ospf. There are however other places where additional code for NEXTHOP_IPV4_IFINDEX is necessary. One of the most apparent is iBGP nexthop resolution. Currently, bgpd is unable to lookup iBGP nexthops which are resolved over a NEXTHOP_IPV4_IFINDEX as that nexthop type is not supported by the nexthop lookup api/protocol. Taking that as an opportunity I did a sweep over the codebase looking out for other places where NEXTHOP_IPV4_IFINDEX should be treated specially which resulted in the following patchset. </pre> Christian Franke 2013-05-25T15:01:33 http://permalink.gmane.org/gmane.network.quagga.devel/10569 <pre>Signed-off-by: Christian Franke &lt;chris&lt; at &gt;opensourcerouting.org&gt; --- bgpd/bgp_nexthop.c | 16 +++++++++++----- zebra/zserv.c | 4 ++++ 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/bgpd/bgp_nexthop.c b/bgpd/bgp_nexthop.c index 69440ce..75b1e9e 100644 --- a/bgpd/bgp_nexthop.c +++ b/bgpd/bgp_nexthop.c &lt; at &gt;&lt; at &gt; -1088,14 +1088,20 &lt; at &gt;&lt; at &gt; bgp_import_check (struct prefix *p, u_int32_t *igpmetric, { nexthop.s_addr = 0; nexthop_type = stream_getc (s); - if (nexthop_type == ZEBRA_NEXTHOP_IPV4) + switch (nexthop_type) { +case ZEBRA_NEXTHOP_IPV4: nexthop.s_addr = stream_get_ipv4 (s); - if (igpnexthop) - *igpnexthop = nexthop; + break; +case ZEBRA_NEXTHOP_IPV4_IFINDEX: + nexthop.s_addr = stream_get_ipv4 (s); + /* ifindex */ (void)stream_getl (s); + break; +default: + /* do nothing */ + break; } - else -*igpnexthop = nexthop; + *igpnexthop = nexthop; return 1; } diff --git a/zebra/zserv.c b/zebra/zserv.c index bcb1680..fa289</pre> Christian Franke 2013-05-25T15:01:36 http://permalink.gmane.org/gmane.network.quagga.devel/10568 <pre>Signed-off-by: Christian Franke &lt;chris&lt; at &gt;opensourcerouting.org&gt; --- zebra/zebra_vty.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/zebra/zebra_vty.c b/zebra/zebra_vty.c index d07b09c..a672d42 100644 --- a/zebra/zebra_vty.c +++ b/zebra/zebra_vty.c &lt; at &gt;&lt; at &gt; -621,7 +621,11 &lt; at &gt;&lt; at &gt; vty_show_ip_route_detail (struct vty *vty, struct route_node *rn) { case NEXTHOP_TYPE_IPV4: case NEXTHOP_TYPE_IPV4_IFINDEX: - vty_out (vty, " via %s)", inet_ntoa (nexthop-&gt;rgate.ipv4)); + vty_out (vty, " via %s", inet_ntoa (nexthop-&gt;rgate.ipv4)); + if (nexthop-&gt;rifindex) + vty_out (vty, ", %s", ifindex2ifname (nexthop-&gt;rifindex)); + vty_out (vty, ")"); + break; case NEXTHOP_TYPE_IFINDEX: case NEXTHOP_TYPE_IFNAME: &lt; at &gt;&lt; at &gt; -731,7 +735,10 &lt; at &gt;&lt; at &gt; vty_show_ip_route (struct vty *vty, struct route_node *rn, struct rib *rib) { case NEXTHOP_TYPE_IPV4: case NEXTHOP_TYPE_IPV4_IFINDEX: - vty_out (vty, " via %s)", inet_ntoa (nexthop-&gt;rgate.ipv4)); + vty_out (vty, " </pre> Christian Franke 2013-05-25T15:01:34 http://permalink.gmane.org/gmane.network.quagga.devel/10567 <pre>Pradosh Mohapatra wrote (on Sun 19-May-2013 at 16:09 +0100): ..... I dunno. The last sentence has all the appearance of a statement of the blindingly obvious. I guess it is meant to mean that you can advertise Graceful Restart for IPv4/Unicast without supporting [BGP-MP]... but (even) in that case, IPv4/Unicast needs to be included explicitly in the list, despite the fact that you: a) don't understand any other afi/safi; b) don't issue any MP-Ext; c) use the encoding of [BGP-4]. If it is meant to mean anything else, then I fear it has gone *way* over my head :-( Chris </pre> 'Chris Hall' 2013-05-22T17:18:36 http://permalink.gmane.org/gmane.network.quagga.devel/10566 <pre>Pradosh Mohapatra wrote (on Sun 19-May-2013 at 16:09 +0100): Ah. This is an interpretation I had not considered :-) So, by this interpretation, the presence of an MP-Ext for a given afi/safi says that the peer supports the sending/receiving of MP_REACH/MP_UNREACH attributes for that afi/safi, and nothing more. Hence: * for IPv4/Unicast, an MP-Ext signals only that MP_REACH/ MP_UNREACH may be used for IPv4/Unicast... ...but, says nothing at all about the exchange of IPv4/Unicast in the "ordinary" or "old" way[1], which is implicitly enabled at all times. * however, for other afi/safi: MP_REACH/MP_UNREACH are essential for the exchange of routes, so the MP-Ext implicitly enables that exchange. OK. If I have understood the interpretation, then now I understand assertions elsewhere that sending an MP-Ext for IPv4/Unicast is not "strictly required" by RFC4760. But that's not to say that I agree with the interpretation[2] :-) ---------------------- Yup: if no MP-Ext at all</pre> 'Chris Hall' 2013-05-21T18:25:12 http://permalink.gmane.org/gmane.network.quagga.devel/10565 <pre>Pradosh Mohapatra wrote (on Sun 19-May-2013 at 16:09 +0100): Ah. This is an interpretation I had not considered :-) So, by this interpretation, the presence of an MP-Ext for a given afi/safi says that the peer supports the sending/receiving of MP_REACH/MP_UNREACH attributes for that afi/safi, and nothing more. Hence: * for IPv4/Unicast, an MP-Ext signals only that MP_REACH/ MP_UNREACH may be used for IPv4/Unicast... ...but, says nothing at all about the exchange of IPv4/Unicast in the "ordinary" or "old" way[1], which is implicitly enabled at all times. * however, for other afi/safi: MP_REACH/MP_UNREACH are essential for the exchange of routes, so the MP-Ext implicitly enables that exchange. OK. If I have understood the interpretation, then now I understand assertions elsewhere that sending an MP-Ext for IPv4/Unicast is not "strictly required" by RFC4760. But that's not to say that I agree with the interpretation[2] :-) ---------------------- Yup: if no MP-Ext at all</pre> 'Chris Hall' 2013-05-21T09:38:00 http://permalink.gmane.org/gmane.network.quagga.devel/10564 <pre> I realize this is open to interpretations in this day and age;-) But strictly speaking, any protocol extension is done in a backward-compatible way. Use of MP_EXT capability is limited to advertisement of prefixes in MP_REACH and MP_UNREACH attributes (IOW, they go hand-in- hand). The speaker is free to send 'ipv4 unicast' prefixes the old way in the 'network layer reachability information' part of the UPDATE message. Thanks, saw that. So the discussion is for the case when the peer didn't send any multi protocol capabilities. I think we agree that this should be fixed to limit it to ipv4-unicast. From RFC4724 (and this seems to imply what you are asking for): Address Family Identifier (AFI), Subsequent Address Family Identifier (SAFI): The AFI and SAFI, taken in combination, indicate that Graceful Restart is supported for routes that are advertised with the same AFI and SAFI. Routes may be explicitly associated with a particular AFI and SAFI us</pre> Pradosh Mohapatra 2013-05-19T15:09:15 http://permalink.gmane.org/gmane.network.quagga.devel/10563 <pre> I agree: - if a neighbor has not announced mp_ext capability listing &lt;afi, safi&gt; = &lt;i, j&gt;, Quagga BGP should not be sending any routes for that &lt;afi, safi&gt; - this rule, however, does not apply to &lt;ipv4 unicast&gt;, as per the original RFC. Quagga BGP can thus send &lt;ipv4 unicast&gt; routes to a speaker in the absence of an mp_ext listing &lt;ipv4 unicast&gt; (even if the neighbor has announced an mp_ext capability, for other &lt;afi, safi&gt; pairs for example). Strange that I don't see this behavior in Quagga (based on a minimal test). Also, from a cursory glance at the code, I see that it does the right thing by checking peer-&gt;afc_nego[afi][safi] while announcing the routes. - Pradosh </pre> Pradosh Mohapatra 2013-05-18T01:06:25 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.network.quagga.devel