From pavlin@icir.org Thu Mar 9 22:18:08 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Thu, 09 Mar 2006 14:18:08 -0800 Subject: [Xorp-announce] Announcing XORP Release 1.2 Message-ID: <200603092218.k29MI80i077022@possum.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.2 Release, which is now available from . The major new features with this release are: * OSPF implementation. * Complete integration of the routing policy mechanism. * Windows support. In addition, this release contains numerous bug fixes. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.3 release; these are documented in the errata section below and in XORP Bugzilla database . In general, to test XORP, we run automated regression tests on a daily basis with various operating systems and compilers. We also run a number of PCs as XORP routers. We have enabled as many protocols as feasible on those routers to test protocol interactions (for example a BGP IPv6 multicast feed being used by PIM-SM). In addition, automated scripts are run to externally toggle BGP peerings. Finally, we have automated scripts that interact directly with the xorpsh to change the configuration settings. We have put significant effort into testing but obviously we have not found all the problems. This is where you can help us to make XORP more stable, by downloading and using it! As always we'd welcome your comments - xorp-users@xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback@xorp.org. - The XORP Team P.S. Release notes and errata are included below. ------------------------------------------------------------------ XORP RELEASE NOTES Release 1.2 (2006/03/08) ========================= ALL: - Numerous improvements, bug fixes and cleanup. - The third-party ospfd implementation is replaced with a new OSPF implementation developed from scratch. - The integration of the routing policy mechanism with the rest of the system is completed. - XORP now builds on Windows Server 2003 (Service Pack 1), amd64+FreeBSD-6.0, FreeBSD-6.1 (BETA3), NetBSD-3.0, OpenBSD-2.8, MacOS X 10.4.5, Linux Fedora Core4 (among others). CONFIGURATION: - Addition of new interface related configuration statement: * restore-original-config-on-shutdown: This optional statement is used to enable the restoring of the original network interface information on shutdown. - Addition of new PIM-SM related configuration statements: * enable-ip-router-alert-option-check: This optional statement is used to enable the IP Router Alert option check per virtual interface. * cand-bsr-by-vif-addr: and * cand-rp-by-vif-addr: Those optional statements are used together with cand-bsr-by-vif-name and cand-rp-by-vif-name respectively to specify the particular IP address on the configured vif. If they are omitted, a domain-wide address (if exists) that belongs to that interface is chosen by the router itself. * hello-period: This optional statement is used to configure the PIM Hello messages period (in seconds). * hello-triggered-delay: This optional statement is used to configure the randomized triggered delay of the PIM Hello messages (in seconds). - Addition of new MLD/IGMP related configuration statements: * version: This optional statement is used to configure the MLD/IGMP protocol version per virtual interface. * enable-ip-router-alert-option-check: This optional statement is used to enable the IP Router Alert option check per virtual interface. * query-interval: This optional statement is used to specify (per virtual interface) the interval between general queries. * query-last-member-interval: This optional statement is used to specify (per virtual interface) the maximum response time inserted into group-specific queries sent in response to leave group messages. * query-response-interval: This optional statement is used to specify (per virtual interface) the maximum response time inserted into the periodic general queries. * robust-count: This optional statement is used to specify (per virtual interface) the robustness variable count that allows tuning for the expected packet loss on a subnet. - Addition of support for user environmental variables CFLAGS_END and CXXFLAGS_END. Those variables can be used to specify the compiler flags (for the C and C++ compiler respectively) that must be after all other flags. LIBXORP: - Various improvements in the RunCommand implementation. LIBXIPC: - No significant changes. LIBFEACLIENT: - No significant changes. XRL: - No significant changes. RTRMGR: - Generalization of the %mandatory keyword syntax so now it can be used to specify any node or variable (multi-value nodes excluded) in the configuration tree. Previously it could be used to specify only configuration child nodes or variables. - Addition of support for read-only, permanent and user-hidden nodes (specified respectively by the new %read-only, %permanent and %user-hidden template commands). - Modification of the %allow and %allow-range semantics so a help string can be supplied for each allowed value or range. - Removal of the mechanism for specifying the hook for saving a configuration file (the "-s " command-line argument). The mechanism is broken and is superseded by the rtrmgr template support for running external programs. - Various other improvements and bug fixes. XORPSH: - Addition of support to run xorpsh in non-interactive mode. - Modification of the configurational mode "show" command so now it displays parameters only if their value is not same as the default value. - Addition of command "show -all" that shows the complete configuration including the parameters with default values. - Modification to the "show" command output: in configuration mode all deleted (and uncommitted) entries are prefixed with "-". - Modification of the default operational and configuration mode prompts to "user@hostname> " and "user@hostname# " respectively. - Addition of support to modify the operational and configuration mode prompts by environmental variables XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION respectively. - Addition of support for command-line completion for allowed values. - Various other improvements and bug fixes. POLICY: - Several bug fixes. FEA/MFEA: - Addition of RawSocket{4,6} generic abstraction that is not multicast-specific. RIB: - Addition of support for displaying the routing tables in brief, detailed and terse format. The default format is "brief". - Few bug fixes. RIP: - The syntax for configuring the authentication mechanism has changed: OLD: authentication { type: "plaintext" password: "FOO" } OR authentication { type: "md5" password: "FOO" } NEW: authentication { simple-password: "FOO" } OR authentication { md5 1 { /* KeyID: [0, 255] */ password: "FOO" start-time: "YYYY-MM-DD.HH:MM" end-time: "YYYY-MM-DD.HH:MM" } } - Several bug fixes. OSPF: - Initial implementation of OSPF that replaces the third-party ospfd. BGP: - The network4/network6 directives have been deprecated. If you wish to inject static routes into BGP, you must now add these routes to the static_routes protocol block, and then configure the policy engine to redistribute them to BGP. - Proper support for policy filters. - Addition of support for route flap damping. - Addition of support for route aggregation. - Addition of support for route reflection. - Addition of support for confederations. - Bug fix to correctly handle connection collisions. - Addition of default support for NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED well-known communities. - Addition of the capability to reconfigure a peering (e.g., from IBGP to EBGP) which requires re-configuring the default filters. - Numerous bug fixes that should greatly improve stability. STATIC_ROUTES: - Several bug fixes. MLD/IGMP: - No significant changes. PIM-SM: - Updated to support the lastest PIM-SM specification (draft-ietf-pim-sm-v2-new-11.{ps,txt}). - Addition of support to disable the "wrong iif" kernel upcall on interfaces we don't need to monitor. - Bug fix related to the handling of the deleted MRIB entries. - Bug fix related to transmitting AssertCancel message when a PIM configured interface is gracefully shutdown. FIB2MRIB: - Several bug fixes. CLI: - Various improvements and bug fixes. SNMP: - No significant changes. ------------------------------------------------------------------ XORP ERRATA ALL: - Parallel building (e.g., "gmake -j 4") may fail on multi-CPU machines. The simplest work-around is to rerun gmake or not to use the -j flag. - The following compiler is known to be buggy, and should not be used to compile XORP: gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD] A newer compiler such as the following should be used instead: gcc34 (GCC) 3.4.2 20040827 (prerelease) [FreeBSD] - If you run BGP, RIB, FIB2MRIB, and PIM-SM at the same time, the propagation latency for the BGP routes to reach the kernel is increased. We are investigating the problem. LIBXORP: - No known issues. LIBXIPC: - No known issues. LIBFEACLIENT: - No known issues. XRL: - No known issues. RTRMGR: - There are several known issues, but none of them is considered critical. The list of known issues is available from: http://www.xorp.org/bugzilla/query.cgi - Using the rtrmgr "-r" command-line option to restart processes that have failed does not work if a process fails while being reconfigured via xorpsh. If that happens, the rtrmgr itself may coredump. Therefore, using the "-r" command-line option is not recommended! Also, note that a process that has been killed by SIGTERM or SIGKILL will not be restarted (this is a feature rather than a bug). Ideally, we want to monitor the processes status using the finder rather than the forked children process status, therefore in the future when we have a more robust implementation the "-r" switch will be removed and will be enabled by default. XORPSH: - There are several known issues, but none of them is considered critical. The list of known issues is available from: http://www.xorp.org/bugzilla/query.cgi FEA/MFEA: - On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel 2.6.5-1.358), some of the tests may fail (with or without an error message), but no coredump image. Some of those failures can be contributed to a kernel problem. E.g., running "dmesg" can show kernel "Oops" messages like: Unable to handle kernel NULL pointer dereference at virtual address 00000000 printing eip: ... This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME) which itself is called by if_indextoname(3). Currently, there is no known solution, but it appears the problem may have been fixed for more recent Linux kernel versions: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697 - The mechanism for tracking the network interface link status may not work for the following OS-es because the kernel for those systems does not provide a mechanism for asynchronous notification of userland programs when the link status changes: FreeBSD-5.2 and earlier and MacOS X (note: if the Windows kernel supports this feature, it is not used yet in XORP). Though, for those systems the link status should be read properly on startup. RIB: - In some rare cases, the RIB may fail to delete an existing route: http://www.xorp.org/bugzilla/show_bug.cgi?id=62 We are aware of the issue and will attempt to fix it in the future. RIP: - No known issues. OSPF: - There are several known issues, but none of them is considered critical. The list of known issues is available from: http://www.xorp.org/bugzilla/query.cgi BGP: - If the RIB bug above (failure to delete an existing route) is triggered by BGP, then the deletion failure error received by BGP from the RIB is considered by BGP as a fatal error. This is not a BGP problem, but a RIB problem that will be fixed in the future. - The BGP configuration mandates that an IPv4 nexthop must be supplied. Unfortunately it is necessary to provide an IPv4 nexthop even for an IPv6 only peering. Even more unfortunately it is not possible to force the IPv6 nexthop. - It is *essential* for an IPv6 peering that an IPv6 nexthop is provided. Unfortunately the configuration does not enforce this requrement. This will be fixed in the future. - If a policy is configured for marking routes as candidates for aggregation, and an update for such a route arrives while a peering is being brought up (XORP is dumping routes to it), a race condition can occur which is considered by BGP as a fatal error. The problem was observed only on IPv6 peerings, and will be fixed in the future. STATIC_ROUTES: - No known issues. MLD/IGMP: - If MLD/IGMP is started on Linux with a relatively large number of interfaces (e.g., on the order of 20), then it may fail with the following error: [ 2004/06/14 12:58:56 ERROR test_pim:16548 MFEA +666 mfea_proto_comm.cc join_multicast_group ] Cannot join group 224.0.0.2 on vif eth8: No buffer space available The solution is to increase the multicast group membership limit. E.g., to increase the value from 20 (the default) to 200, run as a root: echo 200 > /proc/sys/net/ipv4/igmp_max_memberships PIM-SM: - If the kernel does not support PIM-SM, or if PIM-SM is not enabled in the kernel, then running PIM-SM will fail with the following error message: [ 2004/06/12 10:26:41 ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported - On Linux, if the unicast Reverse Path Forwarding information is different from the multicast Reverse Path Forwarding information, the Reverse Path Filtering should be disabled. E.g., as root: echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter OR echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter ... Otherwise, the router will ignore packets if they don't arrive on the reverse-path interface. For more information about Reverse Path Filtering see: http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html - Currently, the PIM-SM implementation does not support unnumbered point-to-point links. Furthermore, even on numbered point-to-point links the next-hop information in the routing entries should use an IP address instead of an interface name. For example, if there is a GRE tunnel on Linux and if we want to add a route that uses that tunnel, we should use a command like: route add -net gw instead of: route add -net FIB2MRIB: - No known issues. CLI: - No known issues. SNMP: - On some versions of Linux, there are some bugs in net-snmp versions 5.0.8 and 5.0.9, which prevent dynamic loading from working. See the following URL for links to the net-snmp patches that solve the problems: http://www.xorp.org/snmp.html - Version 5.1 of net-snmp requires a simple modification, otherwise XORP will fail to compile. See the following URL for a link to the net-snmp patch that solves the problems: http://www.xorp.org/snmp.html From atanu at ICSI.Berkeley.EDU Wed Aug 2 16:37:32 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Wed, 02 Aug 2006 16:37:32 -0700 Subject: [Xorp-announce] Announcing XORP Release 1.3 Message-ID: <75907.1154561852@tigger.icir.org> On behalf of the entire XORP team, I'm delighted to announce the XORP 1.3 Release, which is now available from . The major new features with this release are: * IGMPv3 (RFC 3376) * MLDv2 (RFC 3810) In addition, this release contains numerous bug fixes. There are still a number of non-critical bugs that we know about which will not be addressed until the 1.4 release; these are documented in the XORP Bugzilla database . In general, to test XORP, we run automated regression tests on a daily basis with various operating systems and compilers. We also run a number of PCs as XORP routers. We have enabled as many protocols as feasible on those routers to test protocol interactions (for example a BGP IPv6 multicast feed being used by PIM-SM). In addition, automated scripts are run to externally toggle BGP peerings. Finally, we have automated scripts that interact directly with the xorpsh to change the configuration settings. We have put significant effort into testing but obviously we have not found all the problems. This is where you can help us to make XORP more stable, by downloading and using it! As always we'd welcome your comments - xorp-users at xorp.org is the right place for general discussion, and private feedback to the XORP core team can be sent to feedback at xorp.org. - The XORP Team P.S. Release notes are included below. ------------------------------------------------------------------ XORP RELEASE NOTES This file contains XORP release notes (most recent releases first). Release 1.3 (2006/08/02) ========================= ALL: - Numerous improvements, bug fixes and cleanup. - XORP now builds on Linux Fedora Core5, DragonFlyBSD-1.4, FreeBSD-6.1. - Implementation of IGMPv3 (RFC 3376) and MLDv2 (RFC 3810). Those are necessary to complete the Source-Specific Multicast support. CONFIGURATION: - Addition of new OSPF configuration statement as part of the MD5 keys: * max-time-drift: u32 (default to 3600, i.e., 1 hour) It is used to set the maximum time drift (in seconds) among all OSPF routers. The allowed values are in the range [0--65535]. If the value is 65535, the time drift is unlimited. - The following statements for configuring static routes have been deprecated: route4, route6, interface-route4, interface-route6, mrib-route4, mrib-route6, mrib-interface-route4, mrib-interface-route6. The new replacement statements are: route, interface-route, mrib-route, mrib-interface-route. Each of the new statements can be used to configure either IPv4Net or IPv6Net route. - The following statements for configuring RIP and RIPng have been renamed: * route-expiry-secs -> route-timeout * route-deletion-secs -> deletion-delay * table-request-secs -> request-interval * interpacket-delay-msecs -> interpacket-delay - The following statements for configuring RIP and RIPng random intervals have been replaced: * triggered-update-min-secs and triggered-update-max-secs with triggered-delay and triggered-jitter * table-announce-min-secs and table-announce-max-secs with update-interval and update-jitter Previously, each interval was specified as [foo-min, foo-max]. Now each interval is specified as [foo - foo * jitter / 100, foo + foo * jitter / 100] where "jitter" is specified as a percentage (an integer in the interval [0, 100]) of the value of "foo". - The "version" statement for configuring an IGMP interface/vif allows values in the range [1-3]. Previously, the allowed range was [1-2]. - The "version" statement for configuring a MLD interface/vif allows values in the range [1-2]. Previously, the allowed range was [1-1]. - The following statement for configuring PIM-SM (pimsm4 and pimsm6) has been renamed: interval-sec -> interval - If a "then" policy block contains "accept" or "reject" statement, now all statements inside the "then" block are evaluated regardless of their position. - Addition of a new "exit" operational mode command that is equivalent to the "quit" operational mode command. - The "create" and "set" configuration commands are merged, so now the new "set" command can be used for setting values and for creating new configuration nodes. For backward compatibility, the obsoleted "create" command is preserved as an alias for the new "set" command, though it may be removed in the future. LIBXORP: - Few bug fixes in the RefTrie implementation. LIBXIPC: - Minor improvement in parsing XRL requests. LIBFEACLIENT: - No significant changes. XRL: - No significant changes. RTRMGR: - Various bug fixes. XORPSH: - Previously, the "commit" command was not available in configuration mode if there were no pending configuration changes. Now the "commit" command is always available, but the following message will be printed instead: "No configuration changes to commit." - Various bug fixes. POLICY: - Various bug fixes. FEA/MFEA: - Bug fix in transmitting large packets on Linux when using IP raw sockets. - Linux-related netlink socket code refactoring and bug fix. - Bug fix in obtaining the incoming interface for raw packets (in case of *BSD). - Bug fix in parsing the ancillary data from recvmsg(). - Accept zeroed source addresses of raw packets, because of protocols like IGMPv3. - Bug fix in restoring kernel routes that were automatically removed when the MAC address or MTU on an interface is modified. - Bug fix in processing IPv4 raw packets if they contain an IP option with a bogus option length. RIB: - Several bug fixes and improvements. RIP: - Various bug fixes in the MD5 authentication support. - Remove route flap when applying/deleting RIP-related import policies. - Fix an issue with INFINITY cost routes that might be bounced indefinitely between two XORP routers. OSPF: - Various bug fixes in the MD5 authentication support. BGP: - Prefix limits on a per peer basis. - Various bug fixes. STATIC_ROUTES: - No significant changes. MLD/IGMP: - Implementation of IGMPv3 (RFC 3376) and MLDv2 (RFC 3810). - Unification of the IGMP and MLD execution path. PIM-SM: - Bug fix related to the SPT switch (the bug is *BSD specific). - Use the RPF interface toward the BSR when transmitting a Cand-RP Advertisement message. Previously the first interface that is UP was chosen. - Use the RPF interface toward the RP when transmitting PIM Register messages toward the RP. Previously the interface of the directly connected source was chosen. FIB2MRIB: - No significant changes. CLI: - Bug fix related to tracking the window size when it is resized. SNMP: - No significant changes. From atanu at ICSI.Berkeley.EDU Tue Oct 17 16:01:03 2006 From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh) Date: Tue, 17 Oct 2006 16:01:03 -0700 Subject: [Xorp-announce] XORP_SA_06:01.ospf: An LSA with invalid length will crash OSPFv2 Message-ID: <45609.1161126063@tigger.icir.org> ============================================================================= XORP_SA_06:01.ospf Security Advisory The XORP Project Topic: An LSA with invalid length will crash OSPFv2 Module: OSPF Announced: 2006-10-17 Credits: http://www.musecurity.com/ Affects: XORP 1.2 and XORP 1.3 Releases Corrected: 2006-10-16 06:50:04 UTC (Release 1.4-WIP) I. Background OSPFv2 is a link-state routing protocol defined in RFC 2328, implemented by the XORP project. II. Problem Description The OSPF protocol carries link state information in Link State Advertisements (LSAs). One or more LSAs can be carried in a Link State Update Packet. Each LSA has its own length field and checksum amongst other fields. One of the first checks made when processing an LSA is to verify the checksum. The checksum verification routine takes into account the LSA length field. If the length field has certain invalid values, then OSPF might crash. III. Impact An attacker sending specially crafted packets with certain invalid LSA length value will be able to terminate the XORP OSPF process. It should be noted that the attacker does not need to be on the same network segment as the XORP router. IV. Workaround One possible workaround is to filter all external IP packets with protocol number 89 (OSPF) at the border router. V. Solution Apply the relevant patch to your XORP system and restart OSPF. 1) To patch your present system: [XORP 1.2] # wget http://www.xorp.org/patches/SA-06:01/xorp_sa_06:01.ospf_1.2.patch [XORP 1.3] # wget http://www.xorp.org/patches/SA-06:01/xorp_sa_06:01.ospf_1.3.patch 2) Execute the following commands (only the last one has to be as root): # cd xorp # patch -p0 < /path/to/patch # gmake # cd ospf # gmake install 3) Restart OSPFv2 a) Save the current configuration to a file. # xorpsh Xorp> configure XORP# save /tmp/xorp.boot b) Delete ospf4 from the configuration and commit. OSPFv2 should no longer be running. XORP# delete protocols ospf4 XORP# commit c) Reload the saved configuration, which will restart OSPFv2 XORP# load /tmp/xorp.boot VI. Correction details The following list contains the revision numbers of each file that was corrected in XORP. Branch Revision Path ------------------------------------------------------------------------- HEAD xorp/ospf/lsa.cc 1.72 ------------------------------------------------------------------------- VII. References The latest revision of this advisory is available at: http://www.xorp.org/advisories/XORP_SA_06:01.ospf.txt =============================================================================