Re: IPv6 - real vs theoretical problems
On Jan 6, 2011, at 10:50 PM, Jima wrote: On 1/7/2011 12:11 AM, Owen DeLong wrote: That's a draft, and, it doesn't really eliminate the idea that /48s are generally a good thing so much as it recognizes that there might be SOME circumstances in which they are either not necessary or insufficient. As a draft, it hasn't been through the full process and shouldn't be considered to have the same weight as an RFC. While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may never do so. Fully understood; I wasn't meaning to present it as irrefutable evidence that the /64 /48 mindset is flawed, but as a timely counterpoint to people expounding the virtues of 3177 without cautiously acknowledging that its recommendations aren't necessarily for everyone. I apologize if my intentions weren't terribly clear -- that may be a good cue for me to go to bed. Jima I believe that the draft, even if it were to be adopted as is, does not intend to obsolete the /64, just the /48 recommendation in 3177. Owen
Re: Problems with removing NAT from a network
On Jan 6, 2011, at 11:49 PM, Benson Schliesser wrote: On Jan 7, 2011, at 12:39 AM, Matthew Kaufman wrote: On 1/6/2011 9:28 PM, Dan Wing wrote: Skype could make it work with direct UDP packets in about 92% of cases, per Google's published direct-to-direct statistic at http://code.google.com/apis/talk/libjingle/important_concepts.html If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 solution) on the IPv4 Internet through said NAT64. That's the case we're discussing here. It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now. To paraphrase what you're saying: stuff that embeds and passes around IPv4 addresses will break. I'm sorry to say this, but that's just reality. Embedded IP addresses has always been a Bad Idea (tm) in development and operations, and I don't think P2P protocols get a pass - building your own discovery and topology mechanisms don't insulate you from having to use the underlying network. No, it hasn't always been a Bad Idea. It has been an idea fraught with peril since the deployment of overloaded NAT in IPv4. Fortunately, overloaded NAT will hopefully be a thing of the past in IPv6 and we may get a chance to return to a more functional end-to-end model of networking again. The best chance anybody has, is to build dual-stack support and start using DNS names rather than IP numbers. Oh, and expect IPv4 to start breaking in the near future. We're trying to make IPv4 work long enough to survive the transition, but it's not a good bet for new protocols. On this, at least we agree. Owen
Re: NIST IPv6 document
On Thu, 6 Jan 2011 21:13:52 -0500 Jeff Wheeler j...@inconcepts.biz wrote: On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong o...@delong.com wrote: 1. Block packets destined for your point-to-point links at your borders. There's no legitimate reason someone should be Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those networks want NDP to be the reason they choose to make this change. 2. For networks that aren't intended to receive inbound requests from the outside, limit such requests to the live hosts that exist on those networks with a stateful firewall. Again, this doesn't fix the problem of misconfigured hosts on the LAN. I can and shall say it over and over, as long as folks continue to miss the potential for one compromised machine to disable the entire LAN, and in many cases, the entire router. It is bad that NDP table overflow can be triggered externally, but even if you solve that problem (which again does not require a stateful firewall, why do you keep saying this?) you still haven't made sure one host machine can't disable the LAN/router. Doesn't this risk already exist in IPv4? Any device attached to a LAN can send any traffic it likes to any other device attached to a LAN, whether that be spoofed ARP updates, intentionally created duplicate IP addresses, or simple flat out traffic based denial of service attacks using valid IPv4 addresses. Just relying on ARP means you're trusting other LAN attached devices not be lying. If you really think a LAN attached device being malicious to another LAN attached device is an unacceptable risk, then you're going to need to abandon your peer-to-peer traffic forwarding topology provided by a multi-access LAN, and adopt a hub-and-spoke one, with the hub (router/firewall) acting as an inspection and quarantining device for all traffic originated by spokes. PPPoE or per-device VLANs would be the way to do that, while still gaining the price benefits of commodity Ethernet. I definitely think there is an issue with IPv6 ND cache state being exploitable from off-link sources e.g. the Internet. I think, however, targetting on-link devices on a LAN is far less of an issue - you've already accepted the risk that LAN other devices can send malicious traffic, and those LAN devices also have a vested interest in their default router being available, so they have far less of an incentive to maliciously disable it. 3. Police the ND issue rate on the router. Yes, it means that an ND attack could prevent some legitimate ND requests from getting through, but, at least it prevents ND overflow and the working hosts with existing ND entries continue to function. In most cases, this will be virtually all of the active hosts on the network. You must understand that policing will not stop the NDCache from becoming full almost instantly under an attack. Since the largest existing routers have about 100k entries at most, an attack can fill that up in *one second.* On some platforms, existing entries must be periodically refreshed by actual ARP/NDP exchange. If they are not refreshed, the entries go away, and traffic stops flowing. This is extremely bad because it can break even hosts with constant traffic flows, such as a server or infrastructure link to a neighboring router. Depending on the attack PPS and policer configuration, such hosts may remain broken for the duration of the attack. Implementations differ greatly in this regard. All of them break under an attack. Every single current implementation breaks in some fashion. It's just a question of how bad. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: IPv6 - real vs theoretical problems
Are there any large transit networks doing /64 on point-to-point networks to BGP customers? Who are they? What steps have they taken to eliminate problems, if any? Our Global Crossing IPv6 transit is on a /64 Ethernet point-to-point. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: NIST IPv6 document
On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: Doesn't this risk already exist in IPv4? There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, and as you mention, the ND stuff is layer-3-routable. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: Problems with removing NAT from a network
On Jan 7, 2011, at 4:02 PM, Owen DeLong wrote: No, it hasn't always been a Bad Idea. Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: NIST IPv6 document
Kevin Oberman ober...@es.net writes: The next ship will be departing in a hundred years or so, advance registration for the IPv7 design committee are available over there. Sorry, but IPv7 has come and gone. It was assigned to the TUBA proposal, basically replacing IP with CLNP. IPv8 has also been assigned. (Don't ask as it involved he who must not be named.) In the grand tradition of list pedantry, I must correct both of these statements. :-) IPv7 was TP/IX, which I never really learned anything about (at least nothing that I can remember) at the time. IPv8 was PIP, which got merged with SIP to form SIPP which as I recall evolved into IPv6. It had nothing to do with he who must not be named, but you can't figure this out by googling IPv8 as all it returns is a series of links to flights of fancy. IPv9 was TUBA. Went down for political reasons, but in retrospect perhaps wouldn't have been such a bad thing compred to the second system syndrome design that we find ourselves with today (I know I'm gonna take it on the chin for making such a comment, but whatever). 10-14 are unassigned, guess we'd better get crackin, eh? -r
Re: NANOG 51 (Miami): ISP Security BOF
On Jan 6, 2011, at 8:01 PM, Paul Scanlon wrote: NANOG 51 in Miami is rapidly approaching, January 30 - February 2, and we are looking for topics for the ISP Security BOF. Eric Osterweil and I are going to be moderating this year with the assistance of Danny McPherson. We would very much like to hear your feedback regarding topics of interest for the session. If you have any security related topics that you would like to hear about, not hear about, or be willing to speak about, please let one of us know as soon as possible, feedback to the list obviously welcome. It would be nice if we could get some real intelligence on why the botnets have gone quite. By the time NANOG rolls around, if they are still down, it should be clear they are not just on christmas vacation or whatever. -- TTFN, patrick
Re: NIST IPv6 document
On 6 Jan 2011, at 17:17, Jack Bates wrote: A randomly setup ssh server without DNS will find itself brute force attacked. Darknets are setup specifically for detection of scans. One side effect of v6, is determining how best to deploy darknets, as we can't just take one or two blocks to do it anymore. We'll need to interweave the darknets with the production blocks. I wish it was possible via DHCPv6-PD to assign a block minus a sub-block (hey, don't use this /64 in the /48 I gave you). It could be that darknets will have to go and flow analysis is all we'll be left with. As RFC6018 suggests, this could be done dynamically on any given active subnet. Tim
Re: NIST IPv6 document
On 6 Jan 2011, at 18:20, Owen DeLong wrote: On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote: On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made port-scanning easy, attractive, productive, and commonplace. I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. You are mistaken... Host scanning followed by port sweeps is a very common threat and still widely practiced in IPv4. In our IPv6 enterprise we have not seen any 'traditional' port scans (across IP space), rather we see port sweeps on IPv6 addresses that we expose publicly (DNS servers, web servers, MX servers etc). This is discussed a bit in RFC5157. We have yet to see any of the ND problems discussed in this thread, mainly I believe because our perimeter firewall blacks any such sweeps before they hit the edge router serving the 'attacked' subnet. The main operational problem we see is denial of service caused by unintentional IPv6 RAs from hosts. I think this is an interesting thread though and we'll run some tests internally to see how the issue might (or might not) affect our network. Tim
Re: NIST IPv6 document
On 1/6/2011 6:23 PM, Dobbins, Roland wrote: On Jan 6, 2011, at 9:29 PM, Joe Greco wrote: Sorry, but I see this as not grasping a fundamental security concept. I see it as avoiding a common security misconception. I find that the security Layers advocates tend not to look at the differing value of each of those layers. Going back to the physical door analogy, it's like saying that a bank vault protected by a bank vault door is less secure than a vault with the bank vault door AND a screen door. -- Dave
Re: NIST IPv6 document
On Thu, Jan 6, 2011 at 21:13, Jeff Wheeler j...@inconcepts.biz wrote: On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong o...@delong.com wrote: 1. Block packets destined for your point-to-point links at your borders. There's no legitimate reason someone should be Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those networks want NDP to be the reason they choose to make this change. Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) are to use discrete network allocations for your infrastructure (loopbacks and PtP links, specifically) and to filter traffic destined to those at your edges ... 3. Police the ND issue rate on the router. Yes, it means that an ND attack could prevent some legitimate ND requests from getting through, but, at least it prevents ND overflow and the working hosts with existing ND entries continue to function. In most cases, this will be virtually all of the active hosts on the network. You must understand that policing will not stop the NDCache from becoming full almost instantly under an attack. Since the largest existing routers have about 100k entries at most, an attack can fill that up in *one second.* On some platforms, existing entries must be periodically refreshed by actual ARP/NDP exchange. If they are not refreshed, the entries go away, and traffic stops flowing. This is extremely bad because it can break even hosts with constant traffic flows, such as a server or infrastructure link to a neighboring router. Depending on the attack PPS and policer configuration, such hosts may remain broken for the duration of the attack. Implementations differ greatly in this regard. All of them break under an attack. Every single current implementation breaks in some fashion. It's just a question of how bad. And I am not saying there isn't a concern here that we should get vendors to allow us to mitigate, I think we just disagree on the severity of the issue at hand and the complexity of the solution. /TJ
Re: Problems with removing NAT from a network
On 1/7/2011 4:44 AM, Dobbins, Roland wrote: Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT. Embedding into apps isn't the same as embedding into protocol packets. While NAT and stateful firewalls do tend to break with embedded addresses that they don't know to check for, it's still not a bad idea. I was fixing to complain that the IPv6 designers didn't take the chance to add the embedding to the Packet headers, when it occurs to me, they made the headers nice and extensible. It also baffles me as to why applications such as skype dealing with NAT64 can't use the compatibility addressing to start communicating with v4 hosts from a v6 only NIC. I thought this was already a fixed problem not requiring DNS to deal with. It's not like NAT46 (anyone actually publish such a hideous protocol?), which requires really messy state tables bidirectionally for everything and DNS rewrites. Jack
Re: IPv6 - real vs theoretical problems
On 7 Jan 2011, at 06:11, Owen DeLong wrote: That's a draft, and, it doesn't really eliminate the idea that /48s are generally a good thing so much as it recognizes that there might be SOME circumstances in which they are either not necessary or insufficient. As a draft, it hasn't been through the full process and shouldn't be considered to have the same weight as an RFC. While it intends to obsolete RFC-3177, it doesn't obsolete it yet and, indeed, may never do so. The IETF data tracker shows draft-ietf-v6ops-3177bis-end-sites is under IESG review, with comments currently being made, see https://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/ which also notes the draft has strong support so is likely to be published soon. The document is only guidance regardless. Tim
Re: NIST IPv6 document
On 1/7/2011 8:17 AM, Tim Chown wrote: As RFC6018 suggests, this could be done dynamically on any given active subnet. Unfortunately, I don't see support for it in major router vendors for service providers. Currently, flow + arp/ND/routing tables are utilized to determine a variety of situations, but even then, flow collection is limited at higher speeds. I considered a 1 in 200 approach, but the iBGP tables will go through the roof for a single DHCPv6 pool in a single pop. I a worse problem with darknets than those scanning have with scanning a /64, especially since their scans are likely to be more targeted and not as random. Jack
Re: NIST IPv6 document
On Jan 7, 2011, at 9:30 PM, TJ wrote: Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) are to use discrete network allocations for your infrastructure (loopbacks and PtP links, specifically) and to filter traffic destined to those at your edges ... Actually, this has been an IPv4 BCP for the last decade or so, in order to allow for scalable use of iACLs, CoPP, et. al. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: NIST IPv6 document
On Jan 7, 2011, at 9:23 PM, Tim Chown wrote: The main operational problem we see is denial of service caused by unintentional IPv6 RAs from hosts. Which is a whole other can of IPv6 worms, heh. ; Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: NIST IPv6 document
On Fri, Jan 7, 2011 at 09:57, Dobbins, Roland rdobb...@arbor.net wrote: On Jan 7, 2011, at 9:23 PM, Tim Chown wrote: The main operational problem we see is denial of service caused by unintentional IPv6 RAs from hosts. Which is a whole other can of IPv6 worms, heh. But atleast we are finally getting the solutions for those - RA-Guard, port ACLs, etc. /TJ (PS - Keep pushing vendors for more widespread support for those!)
Re: NIST IPv6 document
On Fri, Jan 7, 2011 at 09:56, Dobbins, Roland rdobb...@arbor.net wrote: On Jan 7, 2011, at 9:30 PM, TJ wrote: Today (IPv4) they may not, but many recommendations for tomorrow (IPv6) are to use discrete network allocations for your infrastructure (loopbacks and PtP links, specifically) and to filter traffic destined to those at your edges ... Actually, this has been an IPv4 BCP for the last decade or so, in order to allow for scalable use of iACLs, CoPP, et. al. True - but some places don't have enough IPv4 address space or willingness to renumber, nor did some have the forethought, to accomplish this ... /TJ
RE: Problems with removing NAT from a network
On 1/6/2011 9:28 PM, Dan Wing wrote: -Original Message- From: Matthew Kaufman [mailto:matt...@matthew.at] Not really. Imagine the case where you're on IPv6 and you can only reach IPv4 via a NAT64, and there's no progress made on the detection problem. And your family member is on a Skype-enabled TV plugged into an IPv4-only ISP. Now you can't get a direct media path between you, even though their ISP is giving them IPv4 and your ISP is *claiming* you can still reach the IPv4 Internet. Skype can still make this work by relaying, Skype could make it work with direct UDP packets in about 92% of cases, per Google's published direct-to-direct statistic at http://code.google.com/apis/talk/libjingle/important_concepts.html If one end is behind a NAT64 and there is no mechanism for discovering the NAT64's IPv6 interface prefix and mapping algorithm (and at present there is not), there is no way to send IPv6 IP packets from the IPv6-only host to IPv4 literal addresses (that is to say, addresses learned via a mechanism other than DNS responses synthesized by the DNS64 part of the NAT64 solution) on the IPv4 Internet through said NAT64. That's the case we're discussing here. There are a bunch of ideas for how to accomplish that. Several of the ideas don't require any support by the network infrastructure, draft-korhonen-behave-nat64-learn-analysis. It breaks Skype, Adobe's RTMFP, BitTorrent, ICE-based NAT traversal, etc. Even the protocol described in the referenced document, Jingle (as it essentially uses ICE) fails. The candidate IPv4 addresses for the end that's on the IPv4 Internet (local and STUN-derived) that are delivered over Jingle's XMPP path cannot be used by the host that is on IPv6 + NAT64 to reach the IPv4 Internet because it has no IPv4 sockets available to it and even if it knew that NAT64 existed (which would take a modification to the Jingle-based apps) and opened an IPv6 socket it wouldn't know what IPv6 address to use to reach the IPv4 host because there's no discovery mechanism. If you want we can take this back to the BEHAVE list now. Sure. -d Matthew Kaufman
Re: Problems with removing NAT from a network
On Jan 7, 2011, at 5:44 AM, Dobbins, Roland wrote: On Jan 7, 2011, at 4:02 PM, Owen DeLong wrote: No, it hasn't always been a Bad Idea. Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT. Let me know when the products from Arbor no longer require this. Thanks. - Jared
Re: IPv6 - real vs theoretical problems
On 1/6/2011 9:01 PM, Jeff Wheeler wrote: Are there any large transit networks doing /64 on point-to-point networks to BGP customers? Who are they? Our Qwest and TW Telecom links are /64. -- Devon
asymmetric routes/security concerns/Fortinet
Hello, we have multiple internet connections of which one is a research network where many medical institutions and universities are also connected to threw out the country. This research network (ORION) also has internet access but is not meant to be used as a primary path to the internet by its customers. Connected to the ORION network are many sites we exchange email with daily who also have multiple internet connections. One of these sites is not reachable by us. After investigating, it was discovered this site is dropping our connections as the path back to use would use a different interface on the firewall ( a Fortinet device) than that which it arrived upon. The admins at this university claim this is by design and for security reasons.. My response was the entire internet is asymmetrical and while this may of been a legitimate concern in the 90's, I don't think its a real concern anymore if things are set up correctly. They suggested we add static routes to our equipment to address this… This seems like a bad idea and I am not comfortable adjusting my routing table to address one site's issues on the internet due to their (not ours) routing/security policies. am I correct here? any comments on this would be greatly appreciated as I'll be called into a meeting to discuss this further (they are digging in their heals in on this, and higher ups are getting involved now). I'd like to arm myself with a few perspectives. thanks very much for your time again, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
Re: IPv6 - real vs theoretical problems
-- Original Message --- From: Jeff Wheeler j...@inconcepts.biz Sent: Thu, 6 Jan 2011 21:01:12 -0500 Are there any large transit networks doing /64 on point-to-point networks to BGP customers? Who are they? Add HE.net to the list. -Randy www.fastserv.com
Re: asymmetric routes/security concerns/Fortinet
On Fri, 7 Jan 2011 12:40:32 -0500 Greg Whynott greg.whyn...@oicr.on.ca wrote: we have multiple internet connections of which one is a research network where many medical institutions and universities are also connected to threw out the country. This research network (ORION) also has internet access but is not meant to be used as a primary path to the internet by its customers. Connected to the ORION network are many sites we exchange email with daily who also have multiple internet connections. One of these sites is not reachable by us. After investigating, it was discovered this site is dropping our connections as the path back to use would use a different interface on the firewall ( a Fortinet device) than that which it arrived upon. Correct me if I'm wrong, I'm not very familiar with ORION, but if it's like some of the research networks in the U.S. have been built in the past, ORION is dedicated high speed, low latency network that interconnects research institutions together. The way these are often used is that you localpref routes you learn from ORION participants so that traffic between each of you goes over the research network. You'd typically want this since the performance is good and there is plenty of capacity available, but it is also paid for, probably through some research grant, helping to reduce the use and expense of your commercial transit. You should be sending your traffic to them via ORION and they likewise. However, if that path is down, then it would make sense for it to go via another route. Hence, asymmetry may happen. Are you not sending the traffic via ORION? If so, then I'd suggest you both have something to fix. :-) John
Re: asymmetric routes/security concerns/Fortinet
Thanks John for your input. You are correct, ORION is a dedicated high speed research network. Based on the fact that we access ORION via one of our ISPs (3rd party, we don't BGP/directly peer with ORION), I'm not sure if i can use this solution here. I could do that for the routes learned from that ISP, but we receive the entire internet routing table from them… I'd have to understand things more before I went down that road. perhaps I shouldn't be accepting the full table from them. the localpref is something I'll look at, thanks for that. I'm not a BGP expert by any stretch, and our requirements here are simple. we are not a transit.I've only attempted to make the config safe, not efficient. i'd like to hear what you have to say about the original question, is there good reason in this day and age to drop traffic as described in the original post in your opinion? -g On Jan 7, 2011, at 1:15 PM, John Kristoff wrote: On Fri, 7 Jan 2011 12:40:32 -0500 Greg Whynott greg.whyn...@oicr.on.ca wrote: we have multiple internet connections of which one is a research network where many medical institutions and universities are also connected to threw out the country. This research network (ORION) also has internet access but is not meant to be used as a primary path to the internet by its customers. Connected to the ORION network are many sites we exchange email with daily who also have multiple internet connections. One of these sites is not reachable by us. After investigating, it was discovered this site is dropping our connections as the path back to use would use a different interface on the firewall ( a Fortinet device) than that which it arrived upon. Correct me if I'm wrong, I'm not very familiar with ORION, but if it's like some of the research networks in the U.S. have been built in the past, ORION is dedicated high speed, low latency network that interconnects research institutions together. The way these are often used is that you localpref routes you learn from ORION participants so that traffic between each of you goes over the research network. You'd typically want this since the performance is good and there is plenty of capacity available, but it is also paid for, probably through some research grant, helping to reduce the use and expense of your commercial transit. You should be sending your traffic to them via ORION and they likewise. However, if that path is down, then it would make sense for it to go via another route. Hence, asymmetry may happen. Are you not sending the traffic via ORION? If so, then I'd suggest you both have something to fix. :-) John -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
Re: NIST IPv6 document
On Thu, 6 Jan 2011, Jeff Wheeler wrote: On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong o...@delong.com wrote: 1. Block packets destined for your point-to-point links at your borders. There's no legitimate reason someone should be Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those networks want NDP to be the reason they choose to make this change. Correct me if I'm wrong, but wouldn't blocking all traffic destined for your infrastructure at the borders also play havoc with PTMUD? Limiting the traffic allowed to just the necessary types would seem like a reasonable alternative. jms
Re: asymmetric routes/security concerns/Fortinet
On Fri, Jan 07, 2011 at 01:56:00PM -0500, Greg Whynott said: Based on the fact that we access ORION via one of our ISPs (3rd party, we don't BGP/directly peer with ORION), I'm not sure if i can use this solution here. I could do that for the routes learned from that ISP, but we receive the entire internet routing table from them? I'd have to understand things more before I went down that road. perhaps I shouldn't be accepting the full table from them. the localpref is something I'll look at, thanks for that. I'm not a BGP expert by any stretch, and our requirements here are simple. we are not a transit. I've only attempted to make the config safe, not efficient. i'd like to hear what you have to say about the original question, is there good reason in this day and age to drop traffic as described in the original post in your opinion? It sounds like the target site has a possible misconfiguration if this is a long term issue. If they're using the open internet to get back to you and not ORION (when your packets arrived from ORION-based connection), then something is misconfigured or down. The problem is a conflict in the way BGP works and how people assume it works :) BGP is designed to get packets to where they want to go, not drop them if they're going the wrong way. The route back to you via ORION might not be available temporarily for a legitimate reason (outtage, etc), or due to other unintentional side effects of preference configurations. They are likely not seeing a route to you being preferred via ORION. Try some traceroutes from your end and from their end and compare. They're likely different paths. However, that shouldnt be suprising - or a reason to filter traffic, really. Symmetric routes across any chunk (big or small) of the internet are a mythological thing of the past. Don't rely on that being the case at any time. As for your getting a full table from your upstream, you would likely expect and want that. Mixed in would be ORION's prefixes, and if things are working right, you are using an ORION path to get to your target. That's up to the upstream's config preferences for packets destined to go through ORION, so if you are the one using the open internet to get to the target (check your traceroutes), then you need to talk to your upstream and get them to fix their route preferences or whatever link or peering session is down. As for dropping traffic, that's a strong fail-fast signal there. If you want to ensure you are getting the intended bandwidth, say if you needed a 100mbps path guaranteed that ORION can easily give you but the open internet/your respective ISPs cant or wont (or you didnt pay for nor want to), then having it fail immediately instead of using a slow backup path might be what you want. There's a balance to be struck between failing fast thus generating sufficient complaints that pressure to fix the best (and only) path that has the required capacity is done ASAP, but then you are also left with no alternate connectivity to the target in the meantime. Which scenario you prefer is up to you and dependant on your organizations' needs. An alternative is to generate sufficient alarms on the best connection's failure, fail over to slower alternates, alert users to the degraded quality (and modify their expectations and behaviour), and have your respective tech teams respond promptly. This all requires awareness, training and a more sophisticated failure-handling system. (How do you automatically alert all users that the alternate degraded path is in use for eg? Email? Pager?) Having alternate connectivity tends to dilute responce urgency from my experience. A question of discipline/(dis)incentives. :) As for using an outtage as a security measure, yes you will reduce the opportunities for the open internet to be a source of spoofed packets from other 'semi-trusted' entities that you expect to only go across ORION for. However, it sounds like you have no opportunity to determine such packets' arrivals/departures, as it all goes through your upstream(s). The other end however seems to have a firewall system that does determine this disparity of paths. This is a minor security benefit, IMHO, which may be worth it to you, depending on how important some connectivity is vs the increased risk of spoofed packets from the general internet during the primary link via ORION's downtime. And, it seems this is the other org's decision to make, not yours, since you dont directly control your own ORION peering, and you are getting a full routing table from your upstream. If you wanted to control your ORION traffic, you would likely get a second BGP feed and link from your upstream if you cant connect to ORION directly somehow. Are you not on TORIX? If so you could connect to ORION directly as we at Heavy Computing do. /kc -g On Jan 7, 2011, at 1:15 PM, John Kristoff wrote: On Fri, 7 Jan 2011 12:40:32 -0500 Greg
Re: asymmetric routes/security concerns/Fortinet
You can allow asymmetric traffic on the Fortinet, but you lose some functionality. Firewalls aren't routers and pretty much all of them behave in the similar manner. On Fri, Jan 7, 2011 at 11:40 AM, Greg Whynott greg.whyn...@oicr.on.ca wrote: Hello, we have multiple internet connections of which one is a research network where many medical institutions and universities are also connected to threw out the country. This research network (ORION) also has internet access but is not meant to be used as a primary path to the internet by its customers. Connected to the ORION network are many sites we exchange email with daily who also have multiple internet connections. One of these sites is not reachable by us. After investigating, it was discovered this site is dropping our connections as the path back to use would use a different interface on the firewall ( a Fortinet device) than that which it arrived upon. The admins at this university claim this is by design and for security reasons.. My response was the entire internet is asymmetrical and while this may of been a legitimate concern in the 90's, I don't think its a real concern anymore if things are set up correctly. They suggested we add static routes to our equipment to address this… This seems like a bad idea and I am not comfortable adjusting my routing table to address one site's issues on the internet due to their (not ours) routing/security policies. am I correct here? any comments on this would be greatly appreciated as I'll be called into a meeting to discuss this further (they are digging in their heals in on this, and higher ups are getting involved now). I'd like to arm myself with a few perspectives. thanks very much for your time again, greg -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
Re: NIST IPv6 document
On Jan 7, 2011, at 6:23 AM, Tim Chown wrote: On 6 Jan 2011, at 18:20, Owen DeLong wrote: On Jan 5, 2011, at 7:18 PM, Dobbins, Roland wrote: On Jan 6, 2011, at 10:08 AM, Joe Greco wrote: Packing everything densely is an obvious problem with IPv4; we learned early on that having a 48-bit (32 address, 16 port) space to scan made port-scanning easy, attractive, productive, and commonplace. I don't believe that host-/port-scanning is as serious a problem as you seem to think it is, nor do I think that trying to somehow prevent host from being host-/port-scanned has any material benefit in terms of security posture, that's our fundamental disagreement. You are mistaken... Host scanning followed by port sweeps is a very common threat and still widely practiced in IPv4. In our IPv6 enterprise we have not seen any 'traditional' port scans (across IP space), rather we see port sweeps on IPv6 addresses that we expose publicly (DNS servers, web servers, MX servers etc). This is discussed a bit in RFC5157. Good for you. We have seen actual host-scanning. It hasn't been particularly successful (firing blind into a very large ocean hoping to hit a whale rarely is), but, nonetheless, we've seen scans go at it for up to 8 hours before they were terminated by the originator. (Very little of a /64 gets scanned in 8 hours, however). We have yet to see any of the ND problems discussed in this thread, mainly I believe because our perimeter firewall blacks any such sweeps before they hit the edge router serving the 'attacked' subnet. Likewise, we haven't seen them. Not even with the active scanning that has been touted as the likely cause thereof. The main operational problem we see is denial of service caused by unintentional IPv6 RAs from hosts. Yep... Push your switch vendors for RA-Guard. This is a very real problem. Right up there with un-intentional 6to4 gateways that don't lead anywhere. Owen
Re: Problems with removing NAT from a network
On Jan 7, 2011, at 6:32 AM, Jack Bates wrote: On 1/7/2011 4:44 AM, Dobbins, Roland wrote: Yes, it has. There're lots of issues with embedding IP addresses directly into apps and so forth which have nothing to do with NAT. Embedding into apps isn't the same as embedding into protocol packets. While NAT and stateful firewalls do tend to break with embedded addresses that they don't know to check for, it's still not a bad idea. I was fixing to complain that the IPv6 designers didn't take the chance to add the embedding to the Packet headers, when it occurs to me, they made the headers nice and extensible. It also baffles me as to why applications such as skype dealing with NAT64 can't use the compatibility addressing to start communicating with v4 hosts from a v6 only NIC. I thought this was already a fixed problem not requiring DNS to deal with. It's not like NAT46 (anyone actually publish such a hideous protocol?), which requires really messy state tables bidirectionally for everything and DNS rewrites. Jack Compatibility addresses don't work on the wire. They're not supposed to. It's a huge problem if they do. Compatibility addresses allow you to write an IPv6 application, run it on a dual-stacked host and talk to the IPv4 and IPv6 remote systems as if all of them are IPv6 hosts. The IPv4 hosts appear to come from the IPv6 range :::ip:v4 which is often presented to the user as :::i.p.v.4 . Hope that clarifies things. Owen
RE: IPv6 - real vs theoretical problems
Thanks Grant, I've already read this. :) I have no problem with enabling /64s for everyone/everything in the future, as the equipment capability increases, but right now there are real concerns about en masse deployment and the vulnerabilities we open our hardware to. Which is why I was talking about reserving the larger block, but only allowing folks to have as much space as they can manage successfully and with a similar risk profile as they have today. Obviously it doesn't take too many people leaving their networks wide to cause a problem for the rest of us. Best, Deepak From: Grant Phillips [mailto:grant.phill...@gwtp.id.au] Sent: Thursday, January 06, 2011 5:47 PM To: Deepak Jain Cc: NANOG list Subject: Re: IPv6 - real vs theoretical problems Hi Deepak, I acknowledge and see the point made. There is a lot of dead space in the IPv6 world. Are we allowing history to repeat it self? Well i'm swaying more to no. Have you read this RFC? This is pretty satisfying in making me feel more comfortable assigning out /48 and /64's. I can sleep at night now! :P http://tools.ietf.org/html//rfc3177http://tools.ietf.org/html/rfc3177 Cheers, Grant Phillips On Fri, Jan 7, 2011 at 9:00 AM, Deepak Jain dee...@ai.netmailto:dee...@ai.net wrote: Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted). While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the host side that presents the most challenge. My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc). Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely? As far as I can tell, this crippling of the address space is completely reversible, it's a reasonable step forward and the only operational loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss. In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so? Thanks, DJ
Re: asymmetric routes/security concerns/Fortinet
Thanks Ken, Some good stuff there, thanks. Since my original email, i think i've come up with a partial solution not requiring the far end's involvement. If not, at least it would get us into a better position to utilize the ORION network when possible. We peer over a L2 tunnel with a router down in the states threw one of our ISP's 10G links, I'm going to see if ORION will do the same with us. This would allow us to establish a BGP session directly with the ORION router, then I could use the localpref options, which may help. this problem is intermitting, most of the time things are fine.doing the above isn't going to help if path/route conditions change, but at least we'll have done all we could within reason and have a proper config. I didn't consider the reasons you mentioned related to 'fail fast', that does make a lot of sense. this is not the reason they claim this policy is in place, it is for security reasons. we access ORION via GTAnet, they are within/part of/something to do with the UoT, and we are across the street. take care, greg @Anthony Pardini t...@pardini.org On Jan 7, 2011, at 2:45 PM, Anthony Pardini wrote: Firewalls aren't routers and pretty much all of them behave in the similar manner. oh! thanks. 8) On Jan 7, 2011, at 2:37 PM, Ken Chase wrote: It sounds like the target site has a possible misconfiguration if this is a long term issue. If they're using the open internet to get back to you and not ORION (when your packets arrived from ORION-based connection), then something is misconfigured or down. The problem is a conflict in the way BGP works and how people assume it works :) BGP is designed to get packets to where they want to go, not drop them if they're going the wrong way. -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization.
Re: asymmetric routes/security concerns/Fortinet
On Fri, Jan 07, 2011 at 03:13:02PM -0500, Greg Whynott said: Thanks Ken, Some good stuff there, thanks. Since my original email, i think i've come up with a partial solution not requiring the far end's involvement. If not, at least it would get us into a better position to utilize the ORION network when possible. We peer over a L2 tunnel with a router down in the states threw one of our ISP's 10G links, I'm going to see if ORION will do the same with us. This would allow us to establish a BGP session directly with the ORION router, then I could use the localpref options, which may help. this problem is intermitting, most of the time things are fine.doing the above isn't going to help if path/route conditions change, but at least we'll have done all we could within reason and have a proper config. I didn't consider the reasons you mentioned related to 'fail fast', that does make a lot of sense. this is not the reason they claim this policy is in place, it is for security reasons. we access ORION via GTAnet, they are within/part of/something to do with the UoT, and we are across the street. Intermittent sounds exactly like what's happening - and alternate routes are being chosen when the main link or peering session is down. And their firewall isnt liking the alternate route and blocking packets. (oddly if their policy is simple enough, you sending packets to them also across the open internet so you both are using it to eachother, might make things work - with a further reduction in (perceived?) security. :) Yes, peering directly with ORION would allow you some control of outgoing packets if that's the issue - ie the issue is you sending via open internet. But if the issue is you receiving via open internet (ie the far side is sending via open internet because their ORION routes are not being preferred to you due to outtage, etc), then you'll have to work with them on their side of the issue. Localpref and other big hammer approaches to preferences are effective but indelicate, and only work on outgoing traffic. Engineering incoming traffic is a black art (there are several vendors that will sell you gear and access to help you of course :) If you are going through an upstream that is also on ORION, their concerns for routing to your target should be convergent with yours. Im suspecting that the issue is at the far end with their firewalling policy and link/session, which are harder for you to fix directly. You could also get a lan extension between your site and theirs directly if you wanted to peer with that entity directly, if signficant/frequent valuable traffic between you is sufficient, and you do not want it to ever pass over the open internet. good luck. /kc take care, greg @Anthony Pardini t...@pardini.org On Jan 7, 2011, at 2:45 PM, Anthony Pardini wrote: Firewalls aren't routers and pretty much all of them behave in the similar manner. oh! thanks. 8) On Jan 7, 2011, at 2:37 PM, Ken Chase wrote: It sounds like the target site has a possible misconfiguration if this is a long term issue. If they're using the open internet to get back to you and not ORION (when your packets arrived from ORION-based connection), then something is misconfigured or down. The problem is a conflict in the way BGP works and how people assume it works :) BGP is designed to get packets to where they want to go, not drop them if they're going the wrong way. -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. -- Ken Chase - k...@heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W.
Re: Problems with removing NAT from a network
On 1/7/2011 1:47 PM, Owen DeLong wrote: Compatibility addresses don't work on the wire. They're not supposed to. It's a huge problem if they do. Sounds like someone should have developed more than 1 compatibility addressing then. Jack
RE: IPv6 - real vs theoretical problems
http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html Jima Just skimming through the draft: 1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site by definition implies multiple subnets and multiple devices. --- I never knew a site, by definition, has multiple subnets and devices. A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space. I think this is the real point everyone is trying to get at. They want IP6 to be the end of NAT. Got it. There are now years of security dogma that says NAT is a good thing, in the 20+ years IP6 has been on the books, the dogma went another way. This concept will take a long time to unwind. Somehow this is supposed to mesh with dynamic renumbering where we can move around between /48s without too much burden while wildly waving our hands at all the higher-level configs (DNS, Applications, firewalls, etc) that don't play nicely with automatic renumbering. There is some convoluted discussion about how they wanted their /48 policy to somehow encourage residential ISPs to give their users more IP space in the base offering. I'm not sure why or what purpose an addressing policy should have to a business case. I see nothing motivating a residential ISP (especially one providing CPE equipment) to change their current deployment system one iota. And I'm pretty sure they are the ones MOST exposed to abuses of this address space by the least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.) Question - Whatever happened to the concept of a customer coming to their SP for more space? Why do we have to give them enough space for a decade of theoretical use when every week we could widen their subnet without causing any negative impact on them? No renumbering, etc. It's not considered a burden today, but under IP6 it is? Heck, since space is so plentiful, we can all set up gateways to do it automatically, but until routers get smarter, I don't see how all that dead routable space is a good thing. Customers are paying for and getting a service, a continuous relationship with some set of SPs. In that service they aren't getting a mathematical representation, they are getting usable IP space, but that doesn't mean that if they hop out of bed in the middle of the night and decide to allocate 5,000,000 unique IPs the SP network should automatically accept it (based on today's current technology). BOGONS, IP hijacks and all the rest seem like the worse problem here and the whole point of putting training wheels on these roll outs. Instead, it seems we are systematically unwinding all the lessons learned from CIDR and going back to addresses being classful, interface links being massive space wasters and no one caring about addresses. That's fine, and probably an improvement, until the next round of attacks and then shortages occur. Once the schools start teaching RFC3177, the hardcoded apps are sure to follow. Deepak
Starbucks network admins
Does anyone have any good contacts for Starbucks network admins? -- Chris Harvey Distinguished Engineer o: 703-939-8479 m: 703-967-4229
RE: IPv6 - real vs theoretical problems
On Fri, 7 Jan 2011, Deepak Jain wrote: least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.) This is exactly the reason to issue /48 or /56 to the end user. You give them plenty of space, and you then don't have to care anymore about what the user does with this space. You keep do LL only between CPE and PE, so you only need to keep 4 TCAM entries per customer (one for the /XX route, one for the LL adjacancy, one for the permit ACL to permit packets from the /XX, and one deny line. (I might be misunderstanding exactly what's needed here and a few TCAM entries more are needed, but you get the idea). until routers get smarter, I don't see how all that dead routable space is a good thing. Customers are paying for and getting a service, a continuous relationship with some set of SPs. In that service they If I give them a /56 then it's zero administration for me for the forseeable future. Why on earth would I want to handle customer administration when I don't need to? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 - real vs theoretical problems
On Fri, Jan 7, 2011 at 3:29 PM, Deepak Jain dee...@ai.net wrote: Question - Whatever happened to the concept of a customer coming to their SP for more space? [E]very week we could widen their subnet without causing any negative impact on them? Clever folks figured that making the customer wait for support hours and then paying people to process configuration changes could be usefully removed from the business cycle? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: NIST IPv6 document
On Fri, 7 Jan 2011 09:38:32 + Dobbins, Roland rdobb...@arbor.net wrote: On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: Doesn't this risk already exist in IPv4? There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, I was commenting on the mentality the OP seemed to be expressing, about *both* onlink and off link sources triggering address resolution for lots of non-existent destinations, and that this was a new and unacceptable threat. I think the offlink risk is a far more significant one. I think the onlink risk pretty much no worse than any of the other things that LAN attached devices can do if they choose to. and as you mention, the ND stuff is layer-3-routable. The issue isn't that ND is layer 3 routable - it isn't unless a router implementation is broken. The problem is that somebody on the Internet could send 1000s of UDP packets (i.e. an offlink traffic source) towards destinations that don't exist on the target subnet. The upstream router will then perform address resolution, sending ND NSes for those unknown destinations, and while waiting to see if ND NAs are returned, will maintain state for each outstanding ND NS. This state is what is exploitable remotely, unless the state table size is large enough to hold all possible outstanding ND NA entries for all possible addresses on the target subnet. I think this problem can be avoided by getting rid of this offlink traffic triggered address resolution state. The purpose of the state (from the Neighbor Discovery RFC) is two fold - - to allow the ND NS to be resent up to two times if no ND NA response is received to ND NSes. A number of triggering packets (e.g. UDP ones or TCP SYNs) are queued as well so that they can be resent if and when ND NS/NA completes. - to allow ICMP destination unreachables to be generated if the ND NS/NA transaction fails, even after resending. I think it is acceptable to compromise on these requirements. ND NS/NA transactions are going to be successful most of the time, so the ND NS/NA retransmit mechanism is going to be rarely used. Original traffic sources have to be prepared for it to fail anyway - the Internet is a best effort network, so if a source node wants to be sure a packet gets to the original destination it needs to be prepared to retransmit it. This has actually proved not to be a problem in IPv4 as Cisco routers have for many years dumped the data packet that triggers ARP, which I'm pretty sure is the reason why the ARP timeout is 4 hours, rather than the more common 5 minutes. Time outs are pretty much moot anyway, because active Neighbor Unreachability Detection is usually performed these days instead of using simple timeouts for existing ARP entries and is required to be performed by IPv6. If you don't maintain state for outstanding ND NS transactions, then that means that the ND NS issuing device will have to just blindly accept any ND NAs it receives at any time, and put them in the neighbor cache, assuming they are correct. That is an vulnerability, as a local node could fill up the neighbor cache with bogus entries, but one that is far less of a risk than the Internet sourced one we're talking about, as it is only onlink devices that can exploit it. As a LAN is already a trusted environment for basic protocol operations, and devices have a vested interest not disabling other devices that provide them with services e.g. default routers, I think it is a reasonable and acceptable risk given those we already accept in LANs, such as the IPv4 ones I mentioned. If it isn't, implement static address resolution entries, PPPoE, per-device VLANs, SEND etc. I doubt I need to go into much detail about whether ICMP destination unreachables need to be reliably received, the reality is that they aren't in IPv4 and I doubt that will change much in IPv6. I think they're a nice to have not a need to have. Regards, Mark.
BGP Update Report
BGP Update Report Interval: 30-Dec-10 -to- 06-Jan-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS18025 31461 3.2% 873.9 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 2 - AS17974 20942 2.1% 17.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 3 - AS810320677 2.1% 55.0 -- STATE-OF-FLA - Florida Department of Management Services - Technology Program 4 - AS32528 19431 2.0%4857.8 -- ABBOTT Abbot Labs 5 - AS33475 18464 1.9% 129.1 -- RSN-1 - RockSolid Network, Inc. 6 - AS24627 17517 1.8% 486.6 -- SHOWNET-KW-AS GULFSATCOMMUNICATIONS COMPANY K.S.C. 7 - AS35931 15601 1.6%5200.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - AS746213969 1.4% 297.2 -- ONEWEST - SRVnet, Inc. 9 - AS24554 12398 1.3% 108.8 -- FIVE-NET-AS-IN Fivenetwork Solution India Pvt Ltd Internet 10 - AS949812353 1.2% 17.5 -- BBIL-AP BHARTI Airtel Ltd. 11 - AS24923 12123 1.2% 12123.0 -- SETTC South-East Transtelecom Joint Stock Co. 12 - AS23700 11034 1.1% 30.1 -- BM-AS-ID PT. Broadband Multimedia, Tbk 13 - AS45474 10393 1.1% 692.9 -- NEXUSGUARD-AS-AP Tower 1 Millennium City 1 14 - AS10113 10157 1.0% 597.5 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 15 - AS245609145 0.9% 8.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 16 - AS9829 9012 0.9% 23.9 -- BSNL-NIB National Internet Backbone 17 - AS256208759 0.9% 62.1 -- COTAS LTDA. 18 - AS5800 8266 0.8% 37.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS8151 6941 0.7% 21.6 -- Uninet S.A. de C.V. 20 - AS455956611 0.7% 13.8 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS24923 12123 1.2% 12123.0 -- SETTC South-East Transtelecom Joint Stock Co. 2 - AS35931 15601 1.6%5200.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS32528 19431 2.0%4857.8 -- ABBOTT Abbot Labs 4 - AS174083041 0.3%3041.0 -- ABOVE-AS-AP AboveNet Communications Taiwan 5 - AS4454 2979 0.3%2979.0 -- TNET-AS - State of Tennessee 6 - AS497761870 0.2%1870.0 -- GORSET-AS Gorodskaya Set Ltd. 7 - AS496001745 0.2%1745.0 -- LASEDA La Seda de Barcelona, S.A 8 - AS8510 1441 0.1%1441.0 -- Tomsk town Educational and Scientific network 9 - AS2828 5679 0.6%1419.8 -- XO-AS15 - XO Communications 10 - AS342391335 0.1%1335.0 -- INTERAMERICAN General Insurance Company 11 - AS435342597 0.3%1298.5 -- CREDITCALL CreditCall Ltd 12 - AS455501221 0.1%1221.0 -- NGT-AS-VN New Generations Telecommunications Corporation 13 - AS2685 1955 0.2% 977.5 -- ASATTCA ATT Global Network Services - CA 14 - AS286664805 0.5% 961.0 -- HOSTLOCATION LTDA 15 - AS21324 926 0.1% 926.0 -- OSW Osrodek Studiow Wschodnich im Marka Karpia 16 - AS1959 2755 0.3% 918.3 -- DMSLABNET - DoD Network Information Center 17 - AS18025 31461 3.2% 873.9 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 18 - AS47722 861 0.1% 861.0 -- CONCORDE-AS Concorde Capital Ltd. 19 - AS27666 814 0.1% 814.0 -- INSTITUTO TECNOLOGICO DE TELEFONOS DE MEXICO 20 - AS21271 798 0.1% 798.0 -- SOTELMABGP TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 194.126.34.0/24 17142 1.6% AS24627 -- SHOWNET-KW-AS GULFSATCOMMUNICATIONS COMPANY K.S.C. 2 - 213.129.96.0/19 12123 1.1% AS24923 -- SETTC South-East Transtelecom Joint Stock Co. 3 - 180.233.173.0/24 10181 1.0% AS45474 -- NEXUSGUARD-AS-AP Tower 1 Millennium City 1 4 - 202.182.78.0/23 10125 1.0% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 5 - 63.211.68.0/2210064 0.9% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 130.36.35.0/24 9716 0.9% AS32528 -- ABBOTT Abbot Labs 7 - 130.36.34.0/24 9711 0.9% AS32528 -- ABBOTT Abbot Labs 8 - 202.92.235.0/247094 0.7% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 9 - 27.123.248.0/226288 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 10 - 182.54.140.0/226279 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 11 - 182.54.148.0/226279 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 12 - 101.78.24.0/22 6129 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 13 - 101.78.20.0/22 6128 0.6% AS18025 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 14 - 198.140.43.0/245446 0.5%
The Cidr Report
This report has been generated at Fri Jan 7 21:11:48 2011 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
31-12-10341294 200729
01-01-11341509 200882
02-01-11341492 200810
03-01-11341470 200862
04-01-11341512 200876
05-01-11341666 200899
06-01-11341989 200893
07-01-11342117 201012
AS Summary
36422 Number of ASes in routing system
15485 Number of ASes announcing only one prefix
3717 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
118804736 Largest address span announced by an AS (/32s)
AS237 : MERIT-ASN Merit Network Inc.
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 07Jan11 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 342320 201017 14130341.3% All ASes
AS6389 3717 271 344692.7% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS4323 2633 405 222884.6% TWTC - tw telecom holdings,
inc.
AS19262 1841 286 155584.5% VZGNI-TRANSIT - Verizon Online
LLC
AS4766 1898 540 135871.5% KIXS-AS-KR Korea Telecom
AS22773 1263 83 118093.4% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS6478 1441 272 116981.1% ATT-INTERNET3 - ATT Services,
Inc.
AS4755 1394 337 105775.8% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS1785 1788 769 101957.0% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS28573 1226 313 91374.5% NET Servicos de Comunicao S.A.
AS7545 1559 714 84554.2% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS6503 1198 362 83669.8% Axtel, S.A.B. de C.V.
AS10620 1344 545 79959.4% Telmex Colombia S.A.
AS18101 913 150 76383.6% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS8151 1409 663 74652.9% Uninet S.A. de C.V.
AS7303 840 122 71885.5% Telecom Argentina S.A.
AS4808 1022 316 70669.1% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS3356 1189 489 70058.9% LEVEL3 Level 3 Communications
AS24560 1060 371 68965.0% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS17488 943 269 67471.5% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS9498 736 108 62885.3% BBIL-AP BHARTI Airtel Ltd.
AS18566 1095 475 62056.6% COVAD - Covad Communications
Co.
AS11492 1283 680 60347.0% CABLEONE - CABLE ONE, INC.
AS17676 645 68 57789.5% GIGAINFRA Softbank BB Corp.
AS855630 55 57591.3% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS4780 749 211 53871.8% SEEDNET Digital United Inc.
AS22047 565 31 53494.5% VTR BANDA ANCHA S.A.
AS14420 593 89 50485.0% CORPORACION NACIONAL DE
TELECOMUNICACIONES - CNT EP
AS7552 632 132 50079.1% VIETEL-AS-AP Vietel
Corporation
AS3549 856 358 49858.2% GBLX Global Crossing Ltd.
AS9443 571 75 49686.9% INTERNETPRIMUS-AS-AP Primus
Telecommunications
Total 37033 95592747474.2% Top 30 total
Possible Bogus Routes
5.0.0.0/8AS237
Re: IPv6 - real vs theoretical problems
On Jan 7, 2011, at 10:12 AM, Randy McAnally wrote: -- Original Message --- From: Jeff Wheeler j...@inconcepts.biz Sent: Thu, 6 Jan 2011 21:01:12 -0500 Are there any large transit networks doing /64 on point-to-point networks to BGP customers? Who are they? Add HE.net to the list. -Randy www.fastserv.com Correct... HE uses /64 on point-to-point links. We give tunnel broker customers a /64 if they only want a single network and a /48 upon request. Owen
Re: NIST IPv6 document
On Jan 7, 2011, at 7:12 AM, Justin M. Streiner wrote: On Thu, 6 Jan 2011, Jeff Wheeler wrote: On Thu, Jan 6, 2011 at 8:47 PM, Owen DeLong o...@delong.com wrote: 1. Block packets destined for your point-to-point links at your borders. There's no legitimate reason someone should be Most networks do not do this today. Whether or not that is wise is questionable, but I don't think those networks want NDP to be the reason they choose to make this change. Correct me if I'm wrong, but wouldn't blocking all traffic destined for your infrastructure at the borders also play havoc with PTMUD? Limiting the traffic allowed to just the necessary types would seem like a reasonable alternative. jms It would only play havoc if your infrastructure is originating packets destined to the outside world from it's link addresses. Generally this shouldn't happen. Remember, I'm only blocking traffic TO the point-to-point LINK networks. Not to the servers, loopbacks, etc. Owen
Re: asymmetric routes/security concerns/Fortinet
On Fri, 7 Jan 2011 13:56:00 -0500 Greg Whynott greg.whyn...@oicr.on.ca wrote: the localpref is something I'll look at, thanks for that. I'm not a BGP expert by any stretch, and our requirements here are simple. we are not a transit.I've only attempted to make the config safe, not efficient. I'm not quite sure I understand what the paths look like, but you could also append your ASN once or twice for your routes on the less preferred path to make the other institution use the more preferred one as long as it is available. i'd like to hear what you have to say about the original question, is there good reason in this day and age to drop traffic as described in the original post in your opinion? Depends on who you ask. I think it clearly shows a mismatch in the assumptions of security devices, engineers and the actual behavior of some deployed networks. Since you're both part of ORION, ideally packets would be following the same path in both directions. I suggest you endeavor to make that the common case. However, to answer your question, dropping packets because the path is asymmetrical would not be something I'd want my university network to be doing. I'd love for them to tell me it's happening though. John
Re: IPv6 - real vs theoretical problems
On Jan 7, 2011, at 12:29 PM, Deepak Jain wrote: http://www.ietf.org/mail-archive/web/v6ops/current/msg06820.html Jima Just skimming through the draft: 1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site by definition implies multiple subnets and multiple devices. --- I never knew a site, by definition, has multiple subnets and devices. A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space. I think this is the real point everyone is trying to get at. They want IP6 to be the end of NAT. Got it. There are now years of security dogma that says NAT is a good thing, in the 20+ years IP6 has been on the books, the dogma went another way. This concept will take a long time to unwind. Somehow this is supposed to mesh with dynamic renumbering where we can move around between /48s without too much burden while wildly waving our hands at all the higher-level configs (DNS, Applications, firewalls, etc) that don't play nicely with automatic renumbering. You say dogma, I say mythology. Stateful inspection provides security. NAT, by itself, does not. The reason people are confused about this is because overloaded NAT cannot occur without stateful inspection. Actually, DNS can be made to play relatively nicely with automatic renumbering and most client hosts don't need DNS entries anyway. Firewalls generally apply policy to network segments and not individual policies to migratory hosts. Yes, it might be nice if they could, but, that's a hard problem to solve in a secure fashion. Generally, nomadic or migratory hosts can usually accept the security policy for the network to which they are attached and augment it with their own host-based firewall/filter rules in any case. In such a case, the host-based rules can be written in terms of interfaces and directions without much regard to the renumbering of the host in question. There is some convoluted discussion about how they wanted their /48 policy to somehow encourage residential ISPs to give their users more IP space in the base offering. I'm not sure why or what purpose an addressing policy should have to a business case. I see nothing motivating a residential ISP (especially one providing CPE equipment) to change their current deployment system one iota. And I'm pretty sure they are the ones MOST exposed to abuses of this address space by the least technical user base. (side note, if I were a residential ISP I'd configure a /64 to my highly-controlled CPE router and issue /128s to each and every device that plugged in on the customer site, and only one per MAC and have a remotely configurable limit of say 50 devices or whatever the mac table limit was. So I only have one route entry in my aggregation layer and if the customer blows his CPE router up, I'm still protected.) If you were an ISP, you wouldn't be one I would subscribe to. There are multiple purposes to /48s to residential end users. DHCP-PD allows a lot of future innovations not yet available. Imagine a house where the border router receives a /48 from the ISP and delegates /64s or /60s or whatever to other routers within the house. Each home entertainment cluster may be one group of networks with its own router. The appliance network(s) may have their own router(s). RFID tags on groceries may lead to a time when your home automation server can gather up data from your refrigerator, pantries, etc. and present the inventory on your mobile phone while you're at the grocery store. No more need to maintain a shopping list, just query the inventory from the store. These are just the things that could easily be done with the technology we already know about. Imagine what we might think of once we get more used to having prefix abundance. Question - Whatever happened to the concept of a customer coming to their SP for more space? Why do we have to give them enough space for a decade of theoretical use when every week we could widen their subnet without causing any negative impact on them? No renumbering, etc. It's not considered a burden today, but under IP6 it is? Heck, since space is so plentiful, we can all set up gateways to do it automatically, but until routers
Re: NIST IPv6 document
On Jan 7, 2011, at 1:28 PM, Mark Smith wrote: On Fri, 7 Jan 2011 09:38:32 + Dobbins, Roland rdobb...@arbor.net wrote: On Jan 7, 2011, at 4:14 PM, Mark Smith wrote: Doesn't this risk already exist in IPv4? There are various vendor knobs/features to ameliorate ARP-level issues in switching gear. Those same knobs aren't viable in IPv6 due to the way ND/NS work, I was commenting on the mentality the OP seemed to be expressing, about *both* onlink and off link sources triggering address resolution for lots of non-existent destinations, and that this was a new and unacceptable threat. I think the offlink risk is a far more significant one. I think the onlink risk pretty much no worse than any of the other things that LAN attached devices can do if they choose to. and as you mention, the ND stuff is layer-3-routable. The issue isn't that ND is layer 3 routable - it isn't unless a router implementation is broken. The problem is that somebody on the Internet could send 1000s of UDP packets (i.e. an offlink traffic source) towards destinations that don't exist on the target subnet. The upstream router will then perform address resolution, sending ND NSes for those unknown destinations, and while waiting to see if ND NAs are returned, will maintain state for each outstanding ND NS. This state is what is exploitable remotely, unless the state table size is large enough to hold all possible outstanding ND NA entries for all possible addresses on the target subnet. I think this problem can be avoided by getting rid of this offlink traffic triggered address resolution state. The purpose of the state (from the Neighbor Discovery RFC) is two fold - - to allow the ND NS to be resent up to two times if no ND NA response is received to ND NSes. A number of triggering packets (e.g. UDP ones or TCP SYNs) are queued as well so that they can be resent if and when ND NS/NA completes. - to allow ICMP destination unreachables to be generated if the ND NS/NA transaction fails, even after resending. I think it is acceptable to compromise on these requirements. I'm inclined to agree with you, but... I think it might also make sense to eliminate the ND NS/NA transaction altogether for addresses that do not begin with ::::000x. In other words, for non SLAAC addresses, we need the ND NS/NA process (even if we do it stateless which isn't an entirely bad idea), but, for SLAAC addresses, the MAC is embedded in the IP address, so, why not just use that? Owen
Gmail Contact
I'm having some issues with personal domains that forward to gmail being blacklist. If anyone from gmail would be available to talk through it with me offlist I would greatly appreciate it. Thanks, Mikeal
Re: IPv6 - real vs theoretical problems
On Jan 8, 2011, at 3:29 AM, Deepak Jain wrote: There are now years of security dogma that says NAT is a good thing, Actually, this isn't the case. There's some *security theater* dogma which makes totally unsupported claims about the supposed security benefits of NAT, but that's not quite the same thing. ; NAT has no inherent security benefits whatsoever, and quite a few security drawbacks. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: IPv6 - real vs theoretical problems
On Jan 8, 2011, at 5:44 AM, Owen DeLong wrote: You say dogma, I say mythology. Concur 100%. Stateful inspection provides security. To clarify, stateful inspection only provides security in a context where there's state to inspect - i.e., at the southernmost end of access networks, directly in front of machines which are serving as client workstations. In all other contexts, such as in front of servers and in the middle of access networks, stateful inspection has no security benefit whatsoever, and is actually quite harmful, with a hugely negative effect on security. ; Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: NIST IPv6 document
On Jan 8, 2011, at 4:28 AM, Mark Smith wrote: The problem is that somebody on the Internet could send 1000s of UDP packets (i.e. an offlink traffic source) towards destinations that don't exist on the target subnet. I meant to type 'ND-triggering stuff', concur 100%. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: asymmetric routes/security concerns/Fortinet
you have sent a message to me which seems to contain a legal warning on who can read it, or how it may be distributed, or whether it may be archived, etc. i do not accept such email. my mail user agent detected a legal notice when i was opening your mail, and automatically deleted it. so do not expect further response. yes, i know your mail environment automatically added the legal notice. well, my mail environment automatically detected it, deleted it, and sent this message to you. so don't expect a lot of sympathy. and if you choose to work for some enterprise clueless enough to think that they can force this silliness on the world, use gmail, hotmail, ... randy
Re: IPv6 - real vs theoretical problems
On Fri, Jan 7, 2011 at 8:02 PM, Dobbins, Roland rdobb...@arbor.net wrote: NAT has no inherent security benefits whatsoever. Hi Roland, With that statement, you paint with a remarkably broad brush. As you know, folks use (or perhaps misuse) the term NAT to describe everything from RFC 1631 to so-called transparent proxies which are basically bastion hosts with some fancy behavior on the interior interface. I presume you don't intend us to conclude that a bastion host firewall provides no security benefit to the equipment it protects. Would you care to clarify which of that range of technologies you consider to serve no security function? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 - real vs theoretical problems
On Jan 8, 2011, at 8:54 AM, William Herrin wrote: I presume you don't intend us to conclude that a bastion host firewall provides no security benefit to the equipment it protects. If it's protecting workstations, yes, it has some positive security value - but not due to NAT. If it's inappropriately placed in front of servers, where's there's no state to inspect and were the stateful nature of the device in and of itself forms a DoS vector, it has negative security value; i.e., it makes things far worse. Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
Re: IPv6 - real vs theoretical problems
On Fri, Jan 7, 2011 at 9:00 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Jan 8, 2011, at 8:54 AM, William Herrin wrote: I presume you don't intend us to conclude that a bastion host firewall provides no security benefit to the equipment it protects. If it's protecting workstations, yes, it has some positive security value - but not due to NAT. Hi Roland, I see. Would I misstate your view if I characterized it as: A bastion host firewall which simulates identical IP addresses on both sides provides at least as effective security as an otherwise identical firewall which does not. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
RE: FAA - ASDI servers
I wanted to thank everyone for both their online and offline replies. At this time the FAA does not support IPv6 to connect to the ASDI servers. Cheers Ryan -Original Message- From: Merike Kaeo [mailto:mer...@doubleshotsecurity.com] Sent: Wednesday, January 05, 2011 12:14 AM To: Ryan Finnesey Cc: nanog@nanog.org Subject: Re: FAA - ASDI servers I've pinged someone offline who may have a contact. Will let you know offline if I do and connect you. I had some peripheral insight a few years ago when I did some work with Boeing. Even had a hand at editing some ARINC standards. The airline industry was umminteresting :) Suffice to say the guy I was working with at Boeing was pushing hard for v6 capability within ARINC and this was 2007. Keep fingers crossed. - merike On Jan 4, 2011, at 8:57 PM, Ryan Finnesey wrote: Can they simply extend the mandate? We need to setup new connectivity to the FFA and was hoping to go IPv6 right out of the gate. Cheers Ryan -Original Message- From: Kevin Oberman [mailto:ober...@es.net] Sent: Tuesday, January 04, 2011 11:12 PM To: Christopher Morrow Cc: Ryan Finnesey; nanog@nanog.org Subject: Re: FAA - ASDI servers Date: Tue, 4 Jan 2011 22:49:34 -0500 From: Christopher Morrow morrowc.li...@gmail.com On Tue, Jan 4, 2011 at 10:39 PM, Ryan Finnesey ryan.finne...@harrierinvestments.com wrote: Very true but why the reference to vacuum tubes? sadly it was an FAA computer system joke. But, since the F stands for Federal, if it is still up in two years, it must be reachable by IPv6. Today, the odds are pretty slim as almost no federal systems are reachable by IPv6. It will be an interesting two years for a lot of federal IT folks as the mandate is from the OMB who can pull a budget for non-compliance. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.netPhone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: AltDB?
note that while i am also an ARIN trustee, i am speaking here as what randy calls just another bozo on this bus. for further background, ISC has done some rpki work and everybody at ISC including me likes rpki just fine. when the ARIN board was first considering funding ISC to do some early rpki work, went out into the hallway until the discussion was over (ending positively.) On Jan 5, 2011, at 12:32 PM, Randy Bush wrote: i have a rumor that arin is delaying and possibly not doing rpki that seems to have been announced on the ppml list (to which i do not subscribe). john curran has explained that arin is doing its due diligence on some concerns that were brought up during a review of the rpki rollout. there is no sense in which arin has said that it is not doing rpki although the current review does technically qualify as delaying rpki. i'm treating the above rumour as false. David Conrad d...@virtualized.org writes: I heard about the delay, but not about ARIN possibly not doing RPKI. That would be ... surprising. [...] it would be very much surprising to me as well. [bush] as it has impact on routing, not address policy, across north america and, in fact the globe, one would think it would be announced and discussed a bit more openly and widely. even if i thought that the operational impact could be felt in these early days when rpki remains an almost completely nonproduction service, and i don't think this by the way, i would still say that an internal review of a new service is not really something the whole community cares about. [conrad] The definition of what comes under the public policy mailing list umbrella has always been a bit confusing to me. Too bad something like the APNIC SIGs and RIPE Working Groups don't really exist in the ARIN region. do you have a specific proposal? i've noted in the past that arin tries hard to stick to its knitting, which is allocation and allocation policy. it seems to me that if some in the community wanted arin to run SIGs or WGs on things like routing policy arin could do it but that a lot of folks would say that's mission creep and that it would be arin poaching on nanog lands. -- Paul Vixie Chairman and Chief Scientist, ISC Trustee, ARIN
Re: AltDB?
[ caveat: i am *one of* the architects of all this, and am paid to work on it, currently (indirectly) by the usg dhs. ] for background, the other four rirs have rolled rpki out in the last weeks, apnic and afrinic with the up/down protocol, ripe web only, and i am not well informed about lacnic's roll out. for the geeky, i append the trust anchor locators for all but afrinic (i'll try to get that). even if i thought that the operational impact could be felt in these early days when rpki remains an almost completely nonproduction service, and i don't think this by the way, i would still say that an internal review of a new service is not really something the whole community cares about. well yes and no. it was important enough that (i have been told) john announced it on major arin mailing list(s). and, as we all know, when info is not openly visible, it gets warped in transmission. hence the (i think you are saying) incorrect impression out here that the bot is questioning rpki roll-out in general. more recent rumors, and john's posting here, seem to indicate that o arin's lawyer, who actually seems to run arin, has created massive fud about liability. o so arin management is seriously reconsidering a web-only roll-out and seriously considering prioritizing being able to delegate the authority to the large isps by implementing the up/down protocol (draft-ietf-sidr-rescerts-provisioning-09.txt). i am a big fan of up/down. i am not a big fan of delay. first, it would really help if the arin bot and management were much more open about these issues and decisions. at the detailed level. we are all not fools out here, present company excepted :). for a radical example, considering that arin is managing a public resource for the community, why are bot meetings not streamed a la cspan? i do not see how you are going to get rid of the liability. you have it now in whois/irr if i use it for routing (except they are so widely known to be bad data that the world knows i would be a fool to bet on them). whether the source of a roa is a user whacking on an arin web page or by other means, you still attested to the rights to that address space. but all this is based on inference and rumor. can you please be more open and direct about this? thanks. randy --- ripe-ncc-root.tal rsync://rpki.afrinic.net/repository/AfriNIC.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxsAqAhWIO+ON2Ef9oRDM pKxv+AfmSLIdLWJtjrvUyDxJPBjgR+kVrOHUeTaujygFUp49tuN5H2C1rUuQavTH vve6xNF5fU3OkTcqEzMOZy+ctkbde2SRMVdvbO22+TH9gNhKDc9l7Vu01qU4LeJH k3X0f5uu5346YrGAOSv6AaYBXVgXxa0s9ZvgqFpim50pReQe/WI3QwFKNgpPzfQL 6Y7fDPYdYaVOXPXSKtx7P4s4KLA/ZWmRL/bobw/i2fFviAGhDrjqqqum+/9w1hEl L/vqihVnV18saKTnLvkItA/Bf5i11Yhw2K7qv573YWxyuqCknO/iYLTR1DToBZcZ UQIDAQAB rsync://repository.lacnic.net/rpki/lacnic/RTA_LACNIC_RPKI.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1AuR49ZoKS59Vnpq8M0X djeV3ROqtElwx6sNmUXvWBFPQlZLs2tR5/0MwprIWRi91WnMBVWjsECcLBe7Pu+u V/tTvPMJRXm/c+l8nR+FhAj7pn4M5A2pHFBndCPc1UrFD+BLACx9DSNiUjzKr1t7 wjHTW+F0NMnZ9g9hKdxDNCFi66BGx2f3TTW3uGns/IPfkxrRCeYtJcBpQ5mKoc8g QOndiEG/33uXDS9EOe1dycmnaw9EQqxqHp+Bj0TIVoFyfDNuT+soJ3uwtQr2g5Ys AIxJtmBAZrLj+acmLeQrYC0xQuK118dSAS9r6GSm476m2aGEYtb083fLodeYSEjM /wIDAQAB rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2m yBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV 2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1p3Ipj2eNc Krmit8BwBC8xImzuCGaV0jkRB0GZ0hoH6Ml03umLprRsn6v0xOP0+l6 Qc1ZHMFVFb385IQ7FQQTcVIxrdeMsoyJq9eMkE6DoclHhF/NlSllXub ASQ9KUWqJ0+Ot3QCXr4LXECMfkpkVR2TZT+v5v658bHVs6ZxRD1b6Uk 1uQKAyHUbn/tXvP8lrjAibGzVsXDT2L0x4Edx+QdixPgOji3gBMyL2V wIDAQAB
Re: AltDB?
Paul,
On Jan 7, 2011, at 7:33 PM, Paul Vixie wrote:
The definition of what comes under the public policy mailing list
umbrella has always been a bit confusing to me. Too bad something like
the APNIC SIGs and RIPE Working Groups don't really exist in the ARIN
region.
do you have a specific proposal? i've noted in the past that arin tries
hard to stick to its knitting, which is allocation and allocation policy.
Yes. This is a positive (IMHO), however it seems that occasionally, ARIN's
knitting tangles up folks who don't necessarily involve themselves with ARIN's
existing interaction mechanisms (at least directly).
it seems to me that if some in the community wanted arin to run SIGs or WGs
on things like routing policy arin could do it but that a lot of folks would
say that's mission creep and that it would be arin poaching on nanog lands.
The issue I see is that there are non-address allocation{, policy} topics that
can deeply affect network operations in which ARIN has a direct role, yet
network operators (outside of the normal ARIN participants) have no obvious
mechanism in which to comment/discuss/etc. Examples would include reverse DNS
operations, whois database-related issues (operations, schema, access methods,
etc.), (potentially?) RPKI, etc. It doesn't seem appropriate to me for these
to be discussed in relation to addressing policy nor are the issues associated
with those examples necessarily related to address allocation, hence I wouldn't
think they'd be fodder for ppml.
In the other regions, the RIRs host the discussions (e.g., for reverse
DNS-related discussions there is dns-wg in RIPE and dns-sig in APNIC, not sure
if there are similar constructs in LACNIC or AfriNIC) and the RIR staff
provides input but (as far as I know) do not direct results. Since the
(non-ARIN) RIRs typically perform some action based on input from these hosted
discussions (or explain to the community why they can't/won't), this works
reasonably well. In the ARIN region, for reasons that you mention among others,
I'm unclear whether there is sufficient trust (on both sides, ARIN or the
ARIN-region network operations community) for ARIN to do something similar
(note I'm not saying there isn't trust, just that I'm not sure that there is).
One alternative (which I suggest being blissfully ignorant of either politics
or establishment mechanisms in NANOG) would be for some sort of joint
ARIN/NANOG interest group (or whatever) for areas that impact ARIN and
network operators in which folks have interest such as routing policy/security,
dns operations, registration data representation/access, etc.
So, in other words, no, I don't really have a specific proposal.
Regards,
-drc
arin and ops fora (was: AltDB? RPKI, the universe, and ...)
The issue I see is that there are non-address allocation{, policy}
topics that can deeply affect network operations in which ARIN has a
direct role, yet network operators (outside of the normal ARIN
participants) have no obvious mechanism in which to
comment/discuss/etc. Examples would include reverse DNS operations,
whois database-related issues (operations, schema, access methods,
etc.), (potentially?) RPKI, etc. It doesn't seem appropriate to me
for these to be discussed in relation to addressing policy nor are the
issues associated with those examples necessarily related to address
allocation, hence I wouldn't think they'd be fodder for ppml.
please $deity no.
one difference in north america from the other 'regions' is that there
is a strong and very separate operator community and forum. this does
not really exist in the other regions. ripe ate the eof years ago.
apops is dormant aside from helping with apricot. afnog has been
strong, but is fading except for the once a year workshops. enredo may
be reborn, but we have yet to see.
observe that the main north american irr, radb, is not run by the rir,
unlike in other regions. and i like that there are a number of diverse
rir services in the region. it's healthy.
so i would be perfectly happy if arin discussed operational matters here
on nanog with the rest of us ops. i would not be pleased to see ops
start to be subsumed by the rir here.
randy
