Foundry MRP cohabit with STP
Hi, We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). Best thanks, Viet Ton.
Re: Foundry MRP cohabit with STP
Hi, You cannot enable MRP and STP on the same physical interface, but you can enable MRP on a specific interface and STP on another, the only issue is MRP and STP are using the CPU, so if you loose a hello packet you may have some network instability. Regards Fabien P.S je suis en France si tu as besoin. Le 15 nov. 2011 à 10:30, Viet-Hung Ton a écrit : Hi, We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). Best thanks, Viet Ton.
Re: Arguing against using public IP space
On 14 Nov 2011, at 18:52, McCall, Gabriel gabriel.mcc...@thyssenkrupp.com wrote: Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. -- Leigh __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Cell-based OOB management devices
David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC David Hubbard dhubb...@dino.hostasaurus.com wrote: Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David
Re: Cell-based OOB management devices
David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC David Hubbard dhubb...@dino.hostasaurus.com wrote: Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David
Re: Cell-based OOB management devices
A very flexible solution can be done with the Mikrotik family of routerssee this as an example for more details.. http://mum.mikrotik.com/presentations/BR09/3G_Applications.pdf Faisal On Nov 15, 2011, at 6:34 AM, rche...@rochester.rr.com wrote: David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC David Hubbard dhubb...@dino.hostasaurus.com wrote: Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David
Re: Arguing against using public IP space
On Tue, 15 Nov 2011 10:57:32 GMT, Leigh Porter said: Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! By the same token, if your firewall fails closed rather than fails open, you're more secure. And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows Firewall has been shipping with inbound default deny since XP SP2 or so. How many years ago was that? And what *real* security over and above that host-based firewall are you getting from that appliance? Or as Dr Phil would say FIrewalls - how is that working out for you? pgpSYl1sOD7us.pgp Description: PGP signature
RE: Arguing against using public IP space
-Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Tuesday, November 15, 2011 9:17 AM To: Leigh Porter Cc: nanog@nanog.org; McCall, Gabriel Subject: Re: Arguing against using public IP space And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows Firewall has been shipping with inbound default deny since XP SP2 or so. How many years ago was that? Simple explanation is that most firewall rules are written to trust traffic initiated by 'inside' (your users), and the return traffic gets trusted as well. This applies to both Window's own FW, and most hardware based firewalls. And NAT/PAT devices too. There's nothing more dangerous than a user with a web browser. Honestly, FWs will keep out attacks initiated from outside. But for traffic permitted or initiated by the inside, IPS is only way to go. Chuck
Re: Arguing against using public IP space
On Nov 14, 2011, at 11:32 AM, William Herrin wrote: On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel gabriel.mcc...@thyssenkrupp.com wrote: Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. The fact that consumer cpe's typically do both nat and stateful firewalling does not mean that those functions are inseparable. Gabriel, This is not accurate. First, many:1 NAT (sometimes also called PAT) is not separable from a stateful firewall. You can build a stateful firewall without many-to-one NAT but the reverse is not possible. Actually, you can. You need a state machine, but, several recent incidents have proven that the state machine in many of the lower-end consumer appliances is not, in fact, a firewall. This has been explained earlier in the thread, so I won't repeat it here. Second, while a security benefit from RFC 1918 addressing combined with 1:1 NAT is dubious at best, the same is not true for the much more commonly implemented many:1 NAT. Repeating this fallacy still doesn't make it true. With RFC1918 plus many:1 NAT, most if not all functions of the interior of the network are not addressable from far locations outside the network, regardless of the correct or incorrect operation of the security apparatus. This is an additional boundary which must be bypassed in order to gain access to the network interior. While there are a variety of techniques for circumventing this boundary no combination of them guarantees successful breach. Hence it provides a security benefit all on its own. If the security apparatus malfunctions, nothing prevents it from malfunctioning in a way that passes packets to the RFC-1918 addressed hosts. You would not rely on NAT+RFC1918 alone to secure a network and neither would I. However, that's far from meaning that the use of RFC1918 is never (or even rarely) operative in a network's security process. RFC-1918 and NAT as a security measure is, at best, a locking screen door deployed in front of a vault door. If you take away the vault door, the screen door really doesn't do much. If the vault door is still there, the presence or absence of the screen door is largely irrelevant. Owen
Minimum Allocation Size by RIRs (IPv4)
I'm trying to compile a comprehensive and up-to-date list of Minimum Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so far: ARIN: https://www.arin.net/knowledge/ip_blocks.html APNIC: http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations (seems that they have recently changed from /22 to /24, which is not too helpful...) RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5 Nothing found for AFRINIC and LACNIC yet, and legacy space, too. -- Fredy Künzler Init Seven AG AS13030 Elias-Canetti-Strasse 7 CH-8050 Zürich Skype: flyingpotato Phone: +41 44 315 4400 Fax: +41 44 315 4401 Twitter: @init7 http://www.init7.net/
Re: Arguing against using public IP space
On Tue, Nov 15, 2011 at 9:17 AM, valdis.kletni...@vt.edu wrote: And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Valdis, A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently. 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: Minimum Allocation Size by RIRs (IPv4)
On Tue, 15 Nov 2011, Fredy Kuenzler wrote: I'm trying to compile a comprehensive and up-to-date list of Minimum Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so far: ARIN: https://www.arin.net/knowledge/ip_blocks.html APNIC: http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations (seems that they have recently changed from /22 to /24, which is not too helpful...) RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5 Nothing found for AFRINIC and LACNIC yet, and legacy space, too. I have some helpful links and at least a starting point for data (a couple of years old now) in this blog entry: http://jonsblog.lewis.org/2008/01/19#bgp -- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Ok; let's have the Does DNAT contribute to Security argument one more time...
On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of NAT contributes no security can't, either. Perhaps this misunderstanding of the job of a firewall explains your errant conclusions about their failure modes better than anything else in the thread. I would say that your description above does not fit a stateful firewall, but, instead describes a packet-filtering router. A stateful firewall's job is to forward only those packets you have permitted. If ti stops doing it's job, it's default failure mode is to stop forwarding packets. Please explain to me how mutilating the packet header makes any difference in this. That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host. Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue. It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue. It's a lovely hypothetical description of how those devices should work. IME, and, as has been explained earlier in the thread, it is not necessarily how they ACTUALLY work. Since security depends not on the theoretical ideal of how the devices should work, but, rather on how they actually work, perhaps it is worth considering that our addressing reality instead of theory is actually a feature rather than a bug. And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports. I think that is what the discussion has been about all along. Owen
Re: Arguing against using public IP space
Guys, Everyone is complaining about whether a FW serves its purpose or not. Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise. I don't think in a large environment you can avoid complexity these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof. -Hammer- I was a normal American nerd -Jack Herer On 11/15/2011 08:56 AM, William Herrin wrote: On Tue, Nov 15, 2011 at 9:17 AM,valdis.kletni...@vt.edu wrote: And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Valdis, A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently. Regards, Bill Herrin
Re: Ok; let's have the Does DNAT contribute to Security argument one more time...
There are some methods of security that NAT has a good use for. We use NAT to prevent reachibility. In other words, not only does an ACL have to allow traffic thru the FW, but a complimenting NAT rule has to allow the actual layer 3 reachibility. If not, even with the ACL, the routing path won't be available. It is a great safety check when we implement FW rules because it forces almost every manual entry to have two specific steps. In our layered environments, we also use local routing in some of our DMZs. In other words, a server on a subnet will only be aware of it's local broadcast domain. Even with a default GW, if it doesn't have a NAT in the FW, it can't route thru it. So even if a server gets compromised, the bad guy doesn't have a method to reach beyond the local DMZ without also making adjustments on the FW. I don't think this complicates our design to much and definitely keeps us in check from human errors. -Hammer- I was a normal American nerd -Jack Herer On 11/15/2011 09:00 AM, Owen DeLong wrote: On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of NAT contributes no security can't, either. Perhaps this misunderstanding of the job of a firewall explains your errant conclusions about their failure modes better than anything else in the thread. I would say that your description above does not fit a stateful firewall, but, instead describes a packet-filtering router. A stateful firewall's job is to forward only those packets you have permitted. If ti stops doing it's job, it's default failure mode is to stop forwarding packets. Please explain to me how mutilating the packet header makes any difference in this. That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host. Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue. It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue. It's a lovely hypothetical description of how those devices should work. IME, and, as has been explained earlier in the thread, it is not necessarily how they ACTUALLY work. Since security depends not on the theoretical ideal of how the devices should work, but, rather on how they actually work, perhaps it is worth considering that our addressing reality instead of theory is actually a feature rather than a bug. And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports. I think that is what the discussion has been about all along. Owen
Re: Arguing against using public IP space
On Nov 15, 2011 7:09 AM, -Hammer- bhmc...@gmail.com wrote: Guys, Everyone is complaining about whether a FW serves its purpose or not. Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise. I would say security is about stopping threats , not layering in technology and tools. Granted, layer is a good idea, throwing everything including the kitchen sink at a problem will result in just a larger problem. I don't think in a large environment you can avoid complexity these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof. Large environments have to force simplicity to combat the natural ebb of complexity. The largest operators live by one rule , KISS. L3 network fw are an attack vector and single point of failure. But, I think this thread is not changing anyone's mind at this point. -Hammer- I was a normal American nerd -Jack Herer On 11/15/2011 08:56 AM, William Herrin wrote: On Tue, Nov 15, 2011 at 9:17 AM,valdis.kletni...@vt.edu wrote: And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Valdis, A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently. Regards, Bill Herrin
Re: Arguing against using public IP space
I see your side Cameron. -Hammer- I was a normal American nerd -Jack Herer On 11/15/2011 09:20 AM, Cameron Byrne wrote: On Nov 15, 2011 7:09 AM, -Hammer- bhmc...@gmail.com mailto:bhmc...@gmail.com wrote: Guys, Everyone is complaining about whether a FW serves its purpose or not. Take a step back. Security is about layers. Router ACLs to filter whitenoise. FW ACLs to filter more. L7 (application) FWs to inspect HTTP payload. Patch management at the OS and Application layer on the server. Heuristics analyzing strategically placed SPAN feeds. The list goes on depending upon the size of your enterprise. I would say security is about stopping threats , not layering in technology and tools. Granted, layer is a good idea, throwing everything including the kitchen sink at a problem will result in just a larger problem. I don't think in a large environment you can avoid complexity these days. What you have to succeed at is managing that complexity. And L3 FWs have a very important purpose. They filter garbage. You focus your IDS/IPS on what the FW is allowing. It's more than a screen door. But yes, it's LESS than a true vault door. It's all about mitigating the risk. You'll never be 100% full proof. Large environments have to force simplicity to combat the natural ebb of complexity. The largest operators live by one rule , KISS. L3 network fw are an attack vector and single point of failure. But, I think this thread is not changing anyone's mind at this point. -Hammer- I was a normal American nerd -Jack Herer On 11/15/2011 08:56 AM, William Herrin wrote: On Tue, Nov 15, 2011 at 9:17 AM,valdis.kletni...@vt.edu mailto:valdis.kletni...@vt.edu wrote: And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Valdis, A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently. Regards, Bill Herrin
Re: Arguing against using public IP space
On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote: On 14 Nov 2011, at 18:52, McCall, Gabriel gabriel.mcc...@thyssenkrupp.com wrote: Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! This is not true. If your firewall is not working, it should not be passing packets. If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a failure of the network implementor and the address space will not have any impact whatsoever on your lack of security. As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. So does a firewall. Owen
Re: Ok; let's have the Does DNAT contribute to Security argument one more time...
Against my better judgment to get in the middle of this classic discussion, two points... One, many firewalls have fail-safe capabilities, in addition to fail-secure; even if they didn't it could be trivially programmed, or configured to do so in series, and as configuration is fairly arbitrary the comments about how firewalls work aren't really valid. My firewall most certainly works differently than yours ... There are also issues with stateful failover versus stateless failover. The two schools of thought on this issue are, as far as I know: a) Fail as little as possible and as compartmentalized as possible, attempting to keep service online at the expense of security (perhaps) (fail-safe) or b) Fail with the intent to keep the network as secure as possible, even if it means causing total service failure. (fail-secure) I find both to be valid and each network should be individually evaluated for application of A or B. If you have a secretless, isolated, read-only environment there is no reason to be concerned about people mucking about. in theory. Two, I would almost guarantee the combination of NAT+firewall is better than only firewall, however the fact that NAT is inherently stateful and really quite vulnerable to DoS makes for an interesting situation. At least with only firewall you could revert to stateless mode during a translation attack (if you chose 'A'). For a NAT to have a similar approach you would need a dark address pool for static translation... that doesn't seem likely or practical, saving a situation where you paid for address time. On the negative case, not having a NAT implies that you won't have any NAT failures or NAT hardware costs :) Perhaps unnecessary NAT is trading a theoretical protection (routing isolation) for a real vulnerability (trans table overflow). On Tue, Nov 15, 2011 at 10:00 AM, Owen DeLong o...@delong.com wrote: On the other hand, since a firewall's job is to stop packets you don't want, if it stops doing it's just as a firewall, it's likely to keep on doing it's other job: passing packets. It certainly depends on the fundamental design of the firewall, which I can't speak to generally... but you proponents of NAT contributes no security can't, either. Perhaps this misunderstanding of the job of a firewall explains your errant conclusions about their failure modes better than anything else in the thread. I would say that your description above does not fit a stateful firewall, but, instead describes a packet-filtering router. A stateful firewall's job is to forward only those packets you have permitted. If ti stops doing it's job, it's default failure mode is to stop forwarding packets. Please explain to me how mutilating the packet header makes any difference in this. That makes sense, but I'm wondering if that should be considered correct behavior. Obviously a non-consumer grade router can have rules defining what is/isn't PATed in or out, but a Linksys/D-Link/etc should expect everything coming from the outside in to either a) match up with something in the translation table, b) be a service the router itself is hosting (http, etc), or c) be a port it explicitly forwards to the same inside host. Anything not matching one of those 3 categories you'd think could be dropped. Routing without translating ports and addresses seems like the root of the issue. It is. And IME, the people who think NAT provides no security rarely if ever seem to address that aspect of the issue. It's a lovely hypothetical description of how those devices should work. IME, and, as has been explained earlier in the thread, it is not necessarily how they ACTUALLY work. Since security depends not on the theoretical ideal of how the devices should work, but, rather on how they actually work, perhaps it is worth considering that our addressing reality instead of theory is actually a feature rather than a bug. And, for what it's worth, I'm discussing the common case: 1-to-many incoming DNAT; rerouting specific TCP or UDP ports to internal machines, possibly on other ports. I think that is what the discussion has been about all along. Owen
Re: Arguing against using public IP space
If you put a router where you needed a firewall, then, this is not a = failure of the firewall, but, a failure of the network implementor and the address space will not have = any impact whatsoever on your lack of security. And the difference between a router and a firewall is ...? Apparently, one bit. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Minimum Allocation Size by RIRs (IPv4)
Hello Fredy, Am 15.11.2011 15:56, schrieb Fredy Kuenzler: I'm trying to compile a comprehensive and up-to-date list of Minimum Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so far: ARIN: https://www.arin.net/knowledge/ip_blocks.html APNIC: http://www.apnic.net/publications/research-and-insights/ip-address-trends/minimum-allocations (seems that they have recently changed from /22 to /24, which is not too helpful...) RIPE NCC: http://www.ripe.net/ripe/docs/ripe-510#5 Nothing found for AFRINIC and LACNIC yet, and legacy space, too. I made such a list some month ago and also found those links: LACNIC: http://lacnic.net/en/registro/index.html AfriNIC: http://www.afrinic.net/Registration/resources.htm ARIN Micro Allocations: https://www.arin.net/knowledge/micro_allocations.html Regards, Christian Seitz Network Operations -- --- Telefon: +49 (0)30 - 398 02 205 Mobil : +49 (0)172 - 389 8714 Telefax: +49 (0)30 - 398 02 222 E-Mail : se...@strato-rz.de Website: http://www.strato.de/ --- STRATO AG Pascalstr. 10 10587 Berlin --- Vorsitzender des Aufsichtsrates: Dirk Backofen Vorstand: Damian Schmidt (Vorsitz), Julien Ardisson, Christian Mueller, Christoph Steffens, Rene Wienholtz Amtsgericht Berlin-Charlottenburg HRB 79450
Re: Minimum Allocation Size by RIRs (IPv4)
On Tue, Nov 15, 2011 at 9:56 AM, Fredy Kuenzler kuenz...@init7.net wrote: I'm trying to compile a comprehensive and up-to-date list of Minimum Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so far: Hi Fredy, Due to the transfer processes which will sustain IPv4 as the regional free pools exhaust, the minimum allocation size can be expected to drop to /24 in essentially all /8's within the next 24 months. 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: Minimum Allocation Size by RIRs (IPv4)
On Tue, Nov 15, 2011 at 12:56 PM, Fredy Kuenzler kuenz...@init7.net wrote: I'm trying to compile a comprehensive and up-to-date list of Minimum Allocation Sizes by the various RIRs. Any hint would be appreciated. I have so far: NIRs (National Internet Registries) in the APNIC and LACNIC area need to be mapped as well as their policies sometimes differ from the RIRs (although they are converging due to IPv4 exhaustion). LACNIC: /24 - http://lacnic.net/en/politicas/manual3.html NIC.br: /24 - http://registro.br/provedor/numeracao/regras.html NIC.mx: /24 - http://www.iar.mx/jsf/static_content/services/resources_request/portable_ip_asn_wish/eligibilityCheck.jsf Rubens
RE: Cell-based OOB management devices
We do this with att with a custom APN works great no need to VPN. If you want to use Sprint take a look at Sprint Data Link. You can use your IPs on the data cards. Cheers Ryan -Original Message- From: rche...@rochester.rr.com [mailto:rche...@rochester.rr.com] Sent: Tuesday, November 15, 2011 6:41 AM To: nanog@nanog.org; David Hubbard Subject: Re: Cell-based OOB management devices David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC David Hubbard dhubb...@dino.hostasaurus.com wrote: Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David
Re: Arguing against using public IP space
On Nov 15, 2011, at 7:54 AM, Joe Greco wrote: If you put a router where you needed a firewall, then, this is not a = failure of the firewall, but, a failure of the network implementor and the address space will not have = any impact whatsoever on your lack of security. And the difference between a router and a firewall is ...? Apparently, one bit. IMHO, a firewall does not route packets by default, but, rather only forwards those packets which match configured policies. A router, OTOH, routes packets by default, but, may be configured with some policy about which packets to forward. The difference functionally is what happens when the configuration is lost or corrupted. Essentially fail open vs. fail closed. Owen
Re: Arguing against using public IP space
On 15 Nov 2011, at 15:36, Owen DeLong o...@delong.com wrote: On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote: On 14 Nov 2011, at 18:52, McCall, Gabriel gabriel.mcc...@thyssenkrupp.com wrote: Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! This is not true. If your firewall is not working, it should not be passing packets. And of course, things always fail just the way we want them to. If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a failure of the network implementor and the address space will not have any impact whatsoever on your lack of security. This is not really a well made point, sorry. It's about a firewall failing, perhaps due to software error or hardware issue or because somebody failed to correctly configure a firewall rule. The point about private space is that is forces security in a way in which public space and a firewall does not. With private space, you are forces to explicitly configure NAT holes or VPN connections whereas with public space your boxes by default are accessible by the whole Internet. By default, on a private space network, nothing can get to it. As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. So does a firewall. If it fails just how you want it to. -- Leigh __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Arguing against using public IP space
Quite right.. I bet all Iran's nuclear facilities have air gaps but they let people in with laptops and USB sticks. -- Leigh On 15 Nov 2011, at 14:48, Chuck Church chuckchu...@gmail.com wrote: -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Tuesday, November 15, 2011 9:17 AM To: Leigh Porter Cc: nanog@nanog.org; McCall, Gabriel Subject: Re: Arguing against using public IP space And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows Firewall has been shipping with inbound default deny since XP SP2 or so. How many years ago was that? Simple explanation is that most firewall rules are written to trust traffic initiated by 'inside' (your users), and the return traffic gets trusted as well. This applies to both Window's own FW, and most hardware based firewalls. And NAT/PAT devices too. There's nothing more dangerous than a user with a web browser. Honestly, FWs will keep out attacks initiated from outside. But for traffic permitted or initiated by the inside, IPS is only way to go. Chuck __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Cell-based OOB management devices
Second this. Custom APN to ATT with ipsec lan2lan VPN built to the provider. Works great for this. Once you get rid of the vpn need, you can use any cheap console server. I've seen solutions ranging from little opengear boxes (which are great to ship to a remote site to help a tech set something up, BTW), to home-brew solutions involving anything that can run OpenWRT, has a usb port, and can run screen or ser2net. Prices for low volume (10mb/month) data plans typically are less than analog lines, too. On Tue, Nov 15, 2011 at 10:05 AM, Ryan Finnesey rfinne...@gmail.com wrote: We do this with att with a custom APN works great no need to VPN. If you want to use Sprint take a look at Sprint Data Link. You can use your IPs on the data cards. Cheers Ryan -Original Message- From: rche...@rochester.rr.com [mailto:rche...@rochester.rr.com] Sent: Tuesday, November 15, 2011 6:41 AM To: nanog@nanog.org; David Hubbard Subject: Re: Cell-based OOB management devices David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC David Hubbard dhubb...@dino.hostasaurus.com wrote: Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David
Re: Arguing against using public IP space
On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart jer...@mompl.net wrote: William Herrin wrote: If your machine is addressed with a globally routable IP, a trivial failure of your security apparatus leaves your machine addressable from any other host in the entire world which wishes to send it Isn't that the case with IPv6? That the IP is addressable from any host in the entire (IPv6) world? And isn't that considered a good thing? Hi Jeroen, Yes, according to almost every application developer asked it's a good thing. Me? I'm not so sure. Historically, enterprises moved away from global addressability even when IP addresses were free, *before* address scarcity became an issue. There's a lesson in there somewhere and I'm not convinced it's that they were dumb. I don't think that being addressable from anywhere is a security hole in and of itself. It's how you implement and (mis)configure your firewall and related things that is the (potential) security hole. Whether the IP is world addressable or not I agree. That your computer is globally addressable is NOT a security hole. It does not directly or indirectly make you vulnerable to attack. But the inverse doesn't follow. That your computer is not globally addressable ADDS one layer of security in a process you hope has enough layers to prevent an attack from penetrating. And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached. 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: Cell-based OOB management devices
We pay $4 per SIM with att then about $2.50 per MB. Cheers Ryan From: PC [mailto:paul4...@gmail.com] Sent: Tuesday, November 15, 2011 12:15 PM To: Ryan Finnesey Cc: rche...@rochester.rr.com; nanog@nanog.org; David Hubbard Subject: Re: Cell-based OOB management devices Second this. Custom APN to ATT with ipsec lan2lan VPN built to the provider. Works great for this. Once you get rid of the vpn need, you can use any cheap console server. I've seen solutions ranging from little opengear boxes (which are great to ship to a remote site to help a tech set something up, BTW), to home-brew solutions involving anything that can run OpenWRT, has a usb port, and can run screen or ser2net. Prices for low volume (10mb/month) data plans typically are less than analog lines, too. On Tue, Nov 15, 2011 at 10:05 AM, Ryan Finnesey rfinne...@gmail.com wrote: We do this with att with a custom APN works great no need to VPN. If you want to use Sprint take a look at Sprint Data Link. You can use your IPs on the data cards. Cheers Ryan -Original Message- From: rche...@rochester.rr.com [mailto:rche...@rochester.rr.com] Sent: Tuesday, November 15, 2011 6:41 AM To: nanog@nanog.org; David Hubbard Subject: Re: Cell-based OOB management devices David, a Sprint aircard can be had with a static-ip, so that should ease remote connectivity requirements. Or, you can opt for the Datalink (private VPN) service, which separates your aircard traffic from other customers within a VRF, obviating the need to run a separate VPN client. -RC David Hubbard dhubb...@dino.hostasaurus.com wrote: Hi all, I am looking at cellular-based devices as a higher speed alternative to dial-up backup access methods for out of band management during emergencies. I was wondering if anyone had experiences with such devices they could share? Devices I've found include Sierra Wireless AirLink Raven X, Digi's ConnectWAN 3G or 4G and Opengear's ACM5004-G. I have no experience with any but they all appear to support the Sprint network which I assume would be ideal due to not having usage caps on data (currently). The Opengear device runs linux and has four serial ports, a usb port for additional storage and ethernet, so it seems to have some small advantages over the others since it could double as an emergency self-contained management station you can SSH into and run diagnostics from. All appear to have VPN/gateway support. What none of them are clear on is how you would connect to it over cellular since I assume you're just paying for a typical data plan and it will randomly obtain IP addresses. Maybe some type of dynamic dns service so you can easily figure out your device's current IP? How stable is the access to the device? Any idea if any of them can do ipv6? Thanks! David
Re: Arguing against using public IP space
On Tue, 15 Nov 2011 09:56:38 EST, William Herrin said: A firewall's job is to prevent the success of ACTIVE attack vectors against your network. If your firewall successfully restricts attackers to passive attack vectors (drive-by downloads) and social engineering vectors then it has done everything reasonably expected of it. Those other parts of the overall network security picture are dealt with elsewhere in system security apparatus. So it's no mistake than in a discussion of firewalls those two attack vectors do not feature prominently. You missed the point - in the greater scheme of things, the threat model has moved on, so the entire ZOMG We can't deploy IPv6 because there's no NAT for security is a total crock of bovine manure. There are *so many* lower-hanging fruit these days that if you're trying to *actually* improve your site's security, you'd just punt worrying about the NAT stuff and focus on doing a better job defending against the threats that are actually succeeding in breaking into systems. In another year or two, lack of IPv6 deployment is going to start impacting the availability part of the security triad. I'd worry about *that* more than how many NATs can dance on the head of a pin. pgpIMXKnw1AFn.pgp Description: PGP signature
Packets dropped passing from Qwest to Verizon
Hello, I'm looking looking for a POC at Qwest (AS209) or Verizon (AS701) to help diagnose what looks like a stale bogon filter. The packets drop where Qwest (63.146.26.210) peers with Verizon (152.63.2.130). Thanks in advance! Regards, Tim H.
Re: Arguing against using public IP space
On Nov 15, 2011, at 7:54 AM, Joe Greco wrote: If you put a router where you needed a firewall, then, this is not a = failure of the firewall, but, a failure of the network implementor and the address space will not have = any impact whatsoever on your lack of security. And the difference between a router and a firewall is ...? Apparently, one bit. IMHO, a firewall does not route packets by default, but, rather only forwards those packets which match configured policies. A router, OTOH, routes packets by default, but, may be configured with some policy about which packets to forward. The difference functionally is what happens when the configuration is lost or corrupted. Essentially fail open vs. fail closed. 1 vs 0. As I said... one bit. Understanding this fundamental truth is helpful in understanding why people use routers as firewalls and firewalls as routers. Because they're basically the same thing, with a one bit difference. And some products, say like FreeBSD (which forms the heart of things like pfSense, so let's not even begin to argue that it isn't a firewall) can actually be configured to default either way. So basically, while we would all prefer that firewalls default to deny, it probably isn't as important a distinction as this thread is making it out to be, because even a default to deny firewall fails when a naive admin makes a typo and allows all traffic from 0/0 inadvertently. It's just a matter of statistical likelihood. Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Arguing against using public IP space
On Tue, 15 Nov 2011, Joe Greco wrote: Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already. er. you've forgotten en; conf t; ip routing to turn off the default no ip routing (or no ip forwarding is my memory, but my config archive says otherwise) so we had default to deny in routers for a long time -- david raistrickhttp://www.netmeister.org/news/learn2quote.html dr...@icantclick.org http://www.expita.com/nomime.html
Re: Arguing against using public IP space
On Tue, Nov 15, 2011 at 5:57 AM, Leigh Porter leigh.por...@ukbroadband.com wrote: As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. This is a myth; just like NAT provides security is a myth. It doesn't matter if your firewall performs NAT or not; if it fails, traffic will more than likely stop flowing. The conditions for a non-NAT firewall to fail open are very specific. You often need to engineer it to have that functionality. Either type of firewall system can be designed to fail open or fail closed. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Arguing against using public IP space
On Tue, 15 Nov 2011 17:16:23 GMT, Leigh Porter said: Quite right.. I bet all Iran's nuclear facilities have air gaps but they let people in with laptops and USB sticks. And that's the point - *most* networks have so many bigger issues that the whole NAT makes us secure mantra is dangerous self-delusion. If you have machines in the NAT area where you're actually concerned that ZOMG the firewall might fail and expose them, why aren't they airgapped? As the Iranians discovered, if the attacker gets a foothold inside the NAT you're screwed anyhow, and *that* is probably a lot more likely scenario than a fail-open firewall.. pgph1iAeCaxvD.pgp Description: PGP signature
Re: Arguing against using public IP space
On Tue, 15 Nov 2011, Joe Greco wrote: Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already. er. you've forgotten en; conf t; ip routing to turn off the default no ip routing (or no ip forwarding is my memory, but my config archive says otherwise) so we had default to deny in routers for a long time My bad. But seriously, now, I'm going to wander a bit far to make a point that I hope people get. In the '90's, during the rapid ISP growth era, one of the local policies here was that all boxes should be protected by a competent on-box firewall. The problem with this was that it was tough to implement in practice, since for the most part, boxes varied in interface configuration, etc., etc. Writing a custom ruleset for each box was nearly prohibitive. I also had clients where I saw similar problems. You'd see all sorts of pseudo-strange rulesets being written, and wildly differing policies about things like ssh, etc., which made administration a challenge too. But a large percentage seemed to go firewall-free. Bleh. So as part of the standard build, I designed an automatic firewall script that basically looked at the system IP configuration, derived reasonable defaults, and then allowed an abstract policy to be specified, such as TCP_ALLOW=80 443 and the rest was automatic. This may seem trivial to many of you, and I will even concede that it *should* be, but the point is that by having this installed by default, it made it MORE annoying to disable the firewall than it was to create a simple configuration for it. So suddenly all servers built through the build scripts reliably had firewall rules in place. I know some readers here may still be using variations on those scripts, and they've served us well over the years too. Now I want to stress the point here: It wasn't that there was this magic firewall script, because to be sure some engs still rolled their own for various reasons. The point is that SOME firewall was going to be running. And that's the desired result. In any case, to bring the discussion home, I suspect that part of the problem with routers and fw rules is that there's a lack of a default to being firewalled. Because it's hard to do that and do it right without also being so painful that an admin just installs a pass all rule to get things working, and then forgets about it all. Those of you who work for large service providers or enterprises and have this all worked out - well, I'm not talking about you, of course. You have incentive and motivation to get this kind of thing working on your fleets of a thousand routers. Great. But it's still a problem for many others. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Arguing against using public IP space
On 11/15/11 09:15, William Herrin wrote: On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aartjer...@mompl.net wrote: William Herrin wrote: If your machine is addressed with a globally routable IP, a trivial failure of your security apparatus leaves your machine addressable from any other host in the entire world which wishes to send it Isn't that the case with IPv6? That the IP is addressable from any host in the entire (IPv6) world? And isn't that considered a good thing? Hi Jeroen, Yes, according to almost every application developer asked it's a good thing. Me? I'm not so sure. Historically, enterprises moved away from global addressability even when IP addresses were free, *before* address scarcity became an issue. There's a lesson in there somewhere and I'm not convinced it's that they were dumb. And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached. Hi Bill: I am not sure if the enterprises were dumb for doing private address space, but I have a few hints that they might have been. (E.g. there's a *lot* of RFC1918 space out there. Why does the overwhelming majority use 192.168.0.0/24 or 192.168.1.0/24 or 10.0.0.0/24?) But what definitely *is* dumb is are the following two axioms, at least one of which is expressed in the article: 1. You need NAT/private ip address space to have security. 2. Once you have NAT/private ip address space, you have security. On the surface those axioms clearly violate your notion of security layers and they clearly violate common sense. Yet we find them lurking just beneath the surface, including in the debate about the utility of IPv6 ULAs, as well as in the article. michael
Re: Arguing against using public IP space
On 11/13/11 07:36, Jason Lewis wrote: I don't want to start a flame war, but this article seems flawed to me. It seems an IP is an IP. http://www.redtigersecurity.com/security-briefings/2011/9/16/scada-vendors-use-public-routable-ip-addresses-by-default.html I think I could announce private IP space, so doesn't that make this argument invalid? I've always looked at private IP space as more of a resource and management choice and not a security feature. Really, the article doesn't make much sense. The claim is that SCADA systems come with public IP addresses by default and that SCADA engineers are too ignorant of Internet security practices to know to re-configure them. First, the ignorance factor goes right back to the two axioms I mentioned in my reply to Bill. If you aren't paying attention, then you don't have security, regardless of which IP address space you use. Second, there's the point that the SCADA systems come with public IP addresses by default. So what? The article incorrectly confuses public IP addresses with routable IP addresses. As an example, when I worked in the College of Chemistry at UC Berkeley, there was a lab with NMR machines that all came with public IP addresses by default--those of the manufacturer. Of course, since the manufacturer was in Germany, and we were in the US those IP addresses weren't routable in our network. Are SCADA systems similarly configured? The article doesn't say if the manufacturers pre-configure addresses within the client's IP blocks or their own, or even 1.2.3.0/24. If the manufacturer went to the trouble of configuring the system on routable IP addresses, then the SCADA engineer can easily specify which set of addresses. If the manufacturer really does configure public IP addresses by default then it's unlikely that those public IP addresses are actually _routable_ on the network which is using the SCADA system. Oh, and the article treats RFC1918 and RFC4193 is equivalent, which is WRONG WRONG WRONG! michael
Re: Arguing against using public IP space
On Nov 15, 2011, at 9:15 AM, William Herrin wrote: On Mon, Nov 14, 2011 at 7:35 PM, Jeroen van Aart jer...@mompl.net wrote: William Herrin wrote: If your machine is addressed with a globally routable IP, a trivial failure of your security apparatus leaves your machine addressable from any other host in the entire world which wishes to send it Isn't that the case with IPv6? That the IP is addressable from any host in the entire (IPv6) world? And isn't that considered a good thing? Hi Jeroen, Yes, according to almost every application developer asked it's a good thing. Me? I'm not so sure. Historically, enterprises moved away from global addressability even when IP addresses were free, *before* address scarcity became an issue. There's a lesson in there somewhere and I'm not convinced it's that they were dumb. I'm not sure how you can make that case since RFC-1918 and it's predecessors RFC-1597 and RFC-1627 came after address scarcity was already a known problem. The oldest of these three (RFC 1597 is dated March, 1994. IPv6 development (spurred by the fact that IPv4 addresses were becoming scarce) started in earnest somewhere between 1990-1992 depending on who you ask). If your initial assertion were true, then, there might be some sort of lesson from your follow-on statement. In this case, however, since the assertion is false, the follow-on lesson is likely just that some enterprises jumped on the NAT bandwagon sooner than others in pursuit of certain coolness or other convenience factors unrelated to delivering a good internet experience to their end users. Also, since the internet was such a radically different thing back then as compared to what it is now, I'm not sure that any such lesson would inherently be useful in the modern age. I don't think that being addressable from anywhere is a security hole in and of itself. It's how you implement and (mis)configure your firewall and related things that is the (potential) security hole. Whether the IP is world addressable or not I agree. That your computer is globally addressable is NOT a security hole. It does not directly or indirectly make you vulnerable to attack. But the inverse doesn't follow. That your computer is not globally addressable ADDS one layer of security in a process you hope has enough layers to prevent an attack from penetrating. This statement is absurd. I can have a globally unique address on a system that does not have any external connectivity. The fact that the address is global in scope does not in any way make that system any less secure than a system which uses an address that is not globally unique. Addressability is not reachability. Addressability has nothing to do with security. Reachability has a little bit to do with security, but, in any sane modern implementation, not a lot. And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached. This is the only thing you've said here that I can actually agree with. Given the penalties associated with non-global addressing and the rewards available from global addressing combined with the absolutely minimal protection afforded by non-global addressing, I find it hard to imagine a scenario in which the benefits would ever outweigh the costs. Owen
Re: Arguing against using public IP space
On Nov 15, 2011, at 9:14 AM, Leigh Porter wrote: On 15 Nov 2011, at 15:36, Owen DeLong o...@delong.com wrote: On Nov 15, 2011, at 2:57 AM, Leigh Porter wrote: On 14 Nov 2011, at 18:52, McCall, Gabriel gabriel.mcc...@thyssenkrupp.com wrote: Chuck, you're right that this should not happen- but the reason it should not happen is because you have a properly functioning stateful firewall, not because you're using NAT. If your firewall is working properly, then having public addresses behind it is no less secure than private. And if your firewall is not working properly, then having private addresses behind it is no more secure than public. In either case, NAT gains you nothing over what you'd have with a firewalled public-address subnet. Well this is not quite true, is it.. If your firewall is not working and you have private space internally then you are a lot better off then if you have public space internally! So if your firewall is not working then having private space on one side is a hell of a lot more secure! This is not true. If your firewall is not working, it should not be passing packets. And of course, things always fail just the way we want them to. Your stateful firewall is no more likely to fail open than your header-mutilating device. If you put a router where you needed a firewall, then, this is not a failure of the firewall, but, a failure of the network implementor and the address space will not have any impact whatsoever on your lack of security. This is not really a well made point, sorry. It's about a firewall failing, perhaps due to software error or hardware issue or because somebody failed to correctly configure a firewall rule. The assertion I was countering is that a header-mangling device is inherently more secure than a stateful firewall that does not mangle headers. I believe that the above paragraph addresses the fact that both are equally likely to fail in an open manner. The problem I was primarily attempting to convey is that many people confuse packet filtering routers for firewalls. Routers have many ways in which they tend to fail open. Their default unconfigured mode is to pass all traffic. This is not the case with a properly designed stateful firewall. The point about private space is that is forces security in a way in which public space and a firewall does not. And my point is that it does not actually do so. If your header-mutilating device breaks or is badly designed or misconfigured, it is just as likely to pass traffic to your private-addressed internal hosts as a badly designed or misconfigured firewall. The only difference is the trivial difference in what it takes to get said traffic to the appliance in question. With private space, you are forces to explicitly configure NAT holes or VPN connections whereas with public space your boxes by default are accessible by the whole Internet. By default, on a private space network, nothing can get to it. Or deliver packets already addressed to the internal host to the external mac address of the header-mutilating device, or own the internal host through other means and have it create a tunnel which the header-mutilating device happily mistakes for a permitted stateful outbound flow, or... I realize you like to live in this fantasy land where private space makes things more secure because it allows you to be lazy about your security posture in other areas. This is a common fallacy that is well liked by many an IT department in the world. It's still a fallacy, and, arguably one that has systematically reduced security overall. As somebody else mentioned on this thread, a NAT box with private space on one side fails closed. So does a firewall. If it fails just how you want it to. If the firewall's default state is don't forward anything, the likelihood of it failing closed is just as high as the theoretical likelihood that a header-mutilating device will do so. In fact, arguably more so. Owen
Re: Arguing against using public IP space
- Original Message - From: Valdis Kletnieks valdis.kletni...@vt.edu And this is totally overlooking the fact that the vast majority of *actual* attacks these days are web-based drive-bys and similar things that most firewalls are configured to pass through. Think about it - if a NAT'ed firewall provides any real protection against real attacks, why are there still so many zombied systems out there? I mean, Windows Firewall has been shipping with inbound default deny since XP SP2 or so. How many years ago was that? And what *real* security over and above that host-based firewall are you getting from that appliance? Or as Dr Phil would say FIrewalls - how is that working out for you? Do you have actual honest-to-ghod numbers, Valdis? And aren't you making here the same assumption for which we chastise people who run DNS resolvers that wildcard to advertising pages for NXDOMAIN: That all the world's a workstation? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Arguing against using public IP space
- Original Message - From: Owen DeLong o...@delong.com If your firewall is not working, it should not be passing packets. Yes; your arguments all seem to depend on that property being true. But we call it a *failure* for a reason, Owen. What the probability is of a firewall failing in such a fashion as to *stop filtering, but still pass packets* depends -- as you have pointed out -- entirely on its design. As *I* have pointed out, not all firewalls are created equal, and there are a helluva a lot of them out there for which this desirable property *simply is not true*. Sticking your head in the sand on this point is not especially productive. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Have they stopped teaching Defense in Depth?
- Original Message - From: William Herrin b...@herrin.us That your computer is not globally addressable ADDS one layer of security in a process you hope has enough layers to prevent an attack from penetrating. And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached. This is precisely the point I've been trying to make, and it ties in to my observations in response in the SCADA thread: not only does the number of layers matter, so does their thickness. Certainly, if you're trying to air-gap a SCADA network to protect it from attack, then you are admitting a certain degree of vulnerability if your circuit passes through any sort of transport multiplexer, like a DACS, as that's a place an attacker could reconfigure to take control of your traffic. But mounting *that* attack requires insider knowledge of 4 or 5 layers of extra information which will be necessary to exploit such an attack. My estimation is that that makes that layer of your defense in depth thicker than some other layers might be. Those who think NAT provides no security seem still to be mounting the strawman that we think it *provides* security, rather than merely contributing some bits thereto... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Arguing against using public IP space
- Original Message - From: Joe Greco jgr...@ns.sol.net And some products, say like FreeBSD (which forms the heart of things like pfSense, so let's not even begin to argue that it isn't a firewall) can actually be configured to default either way. By Owen's definition, it's not. So basically, while we would all prefer that firewalls default to deny, it probably isn't as important a distinction as this thread is making it out to be, because even a default to deny firewall fails when a naive admin makes a typo and allows all traffic from 0/0 inadvertently. It's just a matter of statistical likelihood. Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already. But you're missing an important point here, Joe: we're not talking about default configuration... we're talking about *failure modes*, which are by definition unpredictable. All you can really do there is figure the probabilities... and the probability is that a *router-based* firewall (which as you and I agree, is a helluva lot of firewalls) will *be more likely* to fail into pass traffic mode than into don't pass traffic mode. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Arguing against using public IP space
- Original Message - From: Owen DeLong o...@delong.com If your firewall is not working, it should not be passing packets. And of course, things always fail just the way we want them to. Your stateful firewall is no more likely to fail open than your header-mutilating device. Please show your work. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Arguing against using public IP space
Sent from my iPad On Nov 15, 2011, at 4:10 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Owen DeLong o...@delong.com If your firewall is not working, it should not be passing packets. Yes; your arguments all seem to depend on that property being true. But we call it a *failure* for a reason, Owen. If your firewall has failed to such an extent, all bets are off about what it does or does not pas regardless of whether or not it mutilates the headers. What the probability is of a firewall failing in such a fashion as to *stop filtering, but still pass packets* depends -- as you have pointed out -- entirely on its design. As *I* have pointed out, not all firewalls are created equal, and there are a helluva a lot of them out there for which this desirable property *simply is not true*. Then I would, by definition call them routers, not firewalls. Sticking your head in the sand on this point is not especially productive. I'm not sticking my head in the sand about anything. I am pointing out that mutilating the packet header only reduces security. It does not improve it. Owen
Re: Have they stopped teaching Defense in Depth?
In message 33284158.2915.1321391772464.javamail.r...@benjamin.baylink.com, Jay Ashworth write s: - Original Message - From: William Herrin b...@herrin.us That your computer is not globally addressable ADDS one layer of security in a process you hope has enough layers to prevent an attack from penetrating. And make no mistake: successful security is about layers, about DEPTH. You can seek layers from other sources but a shallow security process will tend to be easily breached. This is precisely the point I've been trying to make, and it ties in to my observations in response in the SCADA thread: not only does the number of layers matter, so does their thickness. Certainly, if you're trying to air-gap a SCADA network to protect it from attack, then you are admitting a certain degree of vulnerability if your circuit passes through any sort of transport multiplexer, like a DACS, as that's a place an attacker could reconfigure to take control of your traffic. But mounting *that* attack requires insider knowledge of 4 or 5 layers of extra information which will be necessary to exploit such an attack. My estimation is that that makes that layer of your defense in depth thicker than some other layers might be. Those who think NAT provides no security seem still to be mounting the strawman that we think it *provides* security, rather than merely contributing some bits thereto... Most of us actually think that what ever benefit it adds over a firewall is miniscule compared to its negative consequences and once the cost benefit analysis is done that it is not worth it. Remember the cost of NAT is not solely borne by the entity deploying the NAT. If it was there would be little debate here. The cost of you deploying NAT is borne by everyone of us. It add a little bit to the cost of every router. If you want to use unroutable addresses then use a bastion host / proxy. Don't expect to be able to open a TCP socket and have it connect to something on the outside. Do it right or don't do it at all. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Have they stopped teaching Defense in Depth?
On Tue, Nov 15, 2011 at 4:50 PM, Mark Andrews ma...@isc.org wrote: If you want to use unroutable addresses then use a bastion host / proxy. Don't expect to be able to open a TCP socket and have it connect to something on the outside. Do it right or don't do it at all. Mark, What is a modern NAT but a bastion host proxy for which application compatibility has been maximized? 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: Arguing against using public IP space
- Original Message - From: Joe Greco jgr...@ns.sol.net And some products, say like FreeBSD (which forms the heart of things like pfSense, so let's not even begin to argue that it isn't a firewall) can actually be configured to default either way. By Owen's definition, it's not. Then Owen's definition is wrong, because the vast majority of firewall devices out there are software-based devices. So basically, while we would all prefer that firewalls default to deny, it probably isn't as important a distinction as this thread is making it out to be, because even a default to deny firewall fails when a naive admin makes a typo and allows all traffic from 0/0 inadvertently. It's just a matter of statistical likelihood. Or perhaps a better argument would be that routers really ought to default to deny. :-) I'd be fine with that, but I can hear the screaming already. But you're missing an important point here, Joe: we're not talking about default configuration... we're talking about *failure modes*, which are by definition unpredictable. But I'm *not* missing the point. You missed mine. The fact of the matter is that routers don't come with firewall-by-default, we've failed to find ways to make it easier for people to firewall things properly than it is to open the gates. Or even notice that their gates are wide open. That's a problem. All you can really do there is figure the probabilities... and the probability is that a *router-based* firewall (which as you and I agree, is a helluva lot of firewalls) will *be more likely* to fail into pass traffic mode than into don't pass traffic mode. That depends on too many factors to really be able to make that call. On the equally cutting side for NAT proponents, there are some attacks against NAT devices that often succeed that shouldn't. I'm not trying to defend the firewall thing. That discussion is boring and dull, it's about the state of one bit, as I pointed out, which is the NANOG equivalent of how many angels can dance on the head of a pin. I was merely taking what seemed to be a good opportunity to point out that there's a more abstract failing here, which is that we have failed to make it easy to firewall by default. I don't mean default to blocking packets. I mean that we've failed to make it easy for router owners to do abstract things like say this network's a bunch of clients, and should be statefully firewalled for outbound connections only and make it as easy (or easier) to do that than it is to open the connection wide open. Failing to put roadblocks in place where you could have roadblocks makes a network easier to penetrate. But I think I've made my point. The obvious, real, clear problem with many SCADA networks is that they're built out of garbage, with garbage software stacks, with no apparent thought given to security. On the Internet, we've typically dealt with that sort of stuff by beating it senseless (open SMTP relay, etc) and then replacing it. Adding layers to protect the soft gooey center, as someone put it, helps, of course, but is only a band-aid solution. Who here would go passwordless on their OOB management network? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
OpenSource IPTV and VoD Solution
Hello Guys i'm looking for a solution to stream diferent DVB transponders through RTSP VLC look like complicated a bit i use MumuDVB for Multicasting but i didn't found anything for RTSP any help Would by welcome thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (2015) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: OpenSource IPTV and VoD Solution
Have a look at RTMPD [1]. Although it is mainly RTMP, it supports RTSP. [1] http://www.rtmpd.com On Nov 14, 2011, at 8:51 PM, Meftah Tayeb wrote: Hello Guys i'm looking for a solution to stream diferent DVB transponders through RTSP VLC look like complicated a bit i use MumuDVB for Multicasting but i didn't found anything for RTSP any help Would by welcome thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (2015) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com
Re: OpenSource IPTV and VoD Solution
thank you for that is a rtsp server no problem but how do i stream Live DVB traffic through it ? Thank you - Original Message - From: Vlad Galu g...@packetdam.com To: Meftah Tayeb tayeb.mef...@gmail.com Cc: nanog@nanog.org Sent: Wednesday, November 16, 2011 1:28 AM Subject: Re: OpenSource IPTV and VoD Solution Have a look at RTMPD [1]. Although it is mainly RTMP, it supports RTSP. [1] http://www.rtmpd.com On Nov 14, 2011, at 8:51 PM, Meftah Tayeb wrote: Hello Guys i'm looking for a solution to stream diferent DVB transponders through RTSP VLC look like complicated a bit i use MumuDVB for Multicasting but i didn't found anything for RTSP any help Would by welcome thank you Meftah Tayeb IT Consulting http://www.tmvoip.com/ phone: +21321656139 Mobile: +213660347746 __ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (2015) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (2015) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6633 (2015) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: Arguing against using public IP space
In message 29838609.2919.1321392184239.javamail.r...@benjamin.baylink.com, Ja y Ashworth writes: If your firewall is not working, it should not be passing packets. And of course, things always fail just the way we want them to. Your stateful firewall is no more likely to fail open than your header-mutilating device. Please show your work. Prove to me that all NAT won't pass packets not addressed directly to it. Show your work. You are making assumptions about how the NAT is designed. Many NATs only take packets addressed to particular address ranges and process them though the state tables. All the rest of the packets are treated as normal traffic which may or may not be forwarded depending apon the way the base platform is configured which is usually as a router. Many NAT's will honour LSR. Unless you know the internals of a NAT you cannot say whether it fails open or closed. Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit but if it is a targeted attack then yes you can expect to see LSR based attacks which depending apon how the NAT is built may pass through it without even being noticed. Now can we put to bed that NAT provides any real security. If you want security add and configure a firewall. That firewall can be in the same box as the NAT. It can use the same state tables as the NAT but it is the firewall, not the NAT functionality, that provides the protection. Mark Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.co m Designer The Things I Think RFC 210 0 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DI I St Petersburg FL USA http://photo.imageinc.us +1 727 647 127 4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Arguing against using public IP space
On Wed, 2011-11-16 at 12:20 +1100, Mark Andrews wrote: You are making assumptions about how the NAT is designed. [...] Unless you know the internals of a NAT you cannot say whether it fails open or closed. Indeed not! From 2010, during an identical discussion: http://seclists.org/nanog/2010/Apr/1166 To me, fail means that a system stops doing what it was designed to do. The results are by definition undefined. Others seem to think that fail means a kind of default. it is actually feasible to probe through a NAT using LSR. What's LSR in this context? Loose source routing, I'm guessing. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 signature.asc Description: This is a digitally signed message part
Re: Arguing against using public IP space
On Tue, Nov 15, 2011 at 8:20 PM, Mark Andrews ma...@isc.org wrote: Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit Mark, My car can be slim-jimmed. Yet the lock is sufficiently operative in the security process that the two times the vehicle has been broken in to the vagrant put a rock through the window instead of jimmying the lock. That's what it MEANS when you say that there's lower hanging fruit to be found elsewhere. It means that the feature you're describing is operative in the process of obstructing an attacker. As an aside to the debate, I boldly suggest that any firewall vendor which actually implements LSR or any of the IP source route functionality anywhere in their code deserves to be tarred and feathered. The security implications of source routing have been long understood. Code which implements source routing has no business existing in a commercial firewall product where it could accidentally be called. Please, by all means, take this opportunity to out any such errors which you can document. 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: Arguing against using public IP space
In message cap-gugxxm_dci6qrzr2aqmfonkh0afs2xdvvy-h-mpdxcrr...@mail.gmail.com , William Herrin writes: On Tue, Nov 15, 2011 at 8:20 PM, Mark Andrews ma...@isc.org wrote: Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit Mark, My car can be slim-jimmed. Yet the lock is sufficiently operative in the security process that the two times the vehicle has been broken in to the vagrant put a rock through the window instead of jimmying the lock. That's what it MEANS when you say that there's lower hanging fruit to be found elsewhere. It means that the feature you're describing is operative in the process of obstructing an attacker. As an aside to the debate, I boldly suggest that any firewall vendor which actually implements LSR or any of the IP source route functionality anywhere in their code deserves to be tarred and feathered. The security implications of source routing have been long understood. Code which implements source routing has no business existing in a commercial firewall product where it could accidentally be called. Please, by all means, take this opportunity to out any such errors which you can document. Indeed. A NAT mangles packets. A firewall provides protection. You can combine the two but expecting one to do the job of the other is just wrong and doesn't work. Regards, Bill Herrin --=20 William D. Herrin her...@dirtside.com=A0 b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Arguing against using public IP space
- Original Message - From: Mark Andrews ma...@isc.org In message 29838609.2919.1321392184239.javamail.r...@benjamin.baylink.com, Ja y Ashworth writes: If your firewall is not working, it should not be passing packets. And of course, things always fail just the way we want them to. Your stateful firewall is no more likely to fail open than your header-mutilating device. Please show your work. Prove to me that all NAT won't pass packets not addressed directly to it. Show your work. I did not *assert* that. So I don't have to prove that. What I *asserted* was that inbound 1:N DNAT *reduces the probability of an attacker being able to target a specific inbound attack to a specific computer*. QED. You are making assumptions about how the NAT is designed. Many NATs only take packets addressed to particular address ranges and process them though the state tables. All the rest of the packets are treated as normal traffic which may or may not be forwarded depending apon the way the base platform is configured which is usually as a router. Many NAT's will honour LSR. As someone pointed out elsewhere, that's bad, but it's bad whether the box does NAT or not; even if the internal network is unrouted public space, that would be troublesome. Unless you know the internals of a NAT you cannot say whether it fails open or closed. It's probably impossible to determine whether any box's response to any failure will be pass or drop, with any reliability. All you can figure is probabilities. Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit but if it is a targeted attack then yes you can expect to see LSR based attacks which depending apon how the NAT is built may pass through it without even being noticed. Someone else has already addressed low-hanging fruit, so I won't. I do concur, though: if you have specific examples of boxes which, as you allege, respect LSR to 1918 internal addresses, please, name and shame. Now can we put to bed that NAT provides any real security. If you want security add and configure a firewall. That firewall can be in the same box as the NAT. It can use the same state tables as the NAT but it is the firewall, not the NAT functionality, that provides the protection. Nope; I'm afraid we still can't. As long as you continue to strawman that I/we are even *alleging* that NAT provides security (rather than contributing to it, we're just going to keep talking past each other, Mark. As long as you keep defining protection as one thing in one place, I'll keep assuming you're flapping your jaws to dry your teeth. (provides *the* protection) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: Arguing against using public IP space
In message 28327223.2951.1321412909463.javamail.r...@benjamin.baylink.com, Ja y Ashworth writes: - Original Message - From: Mark Andrews ma...@isc.org In message 29838609.2919.1321392184239.javamail.r...@benjamin.baylink.com, Ja y Ashworth writes: If your firewall is not working, it should not be passing packets. And of course, things always fail just the way we want them to. Your stateful firewall is no more likely to fail open than your header-mutilating device. Please show your work. Prove to me that all NAT won't pass packets not addressed directly to it. Show your work. I did not *assert* that. So I don't have to prove that. What I *asserted* was that inbound 1:N DNAT *reduces the probability of an attacker being able to target a specific inbound attack to a specific computer*. QED. You are making assumptions about how the NAT is designed. Many NATs only take packets addressed to particular address ranges and process them though the state tables. All the rest of the packets are treated as normal traffic which may or may not be forwarded depending apon the way the base platform is configured which is usually as a router. Many NAT's will honour LSR. As someone pointed out elsewhere, that's bad, but it's bad whether the box does NAT or not; even if the internal network is unrouted public space, that would be troublesome. Actually LSR is not bad in and of itself. The actual problem was badly designed firewall code that failed properly examine the LSR option. Rather than fix the firewall code people choose to drop packets with LSR options. Unless you know the internals of a NAT you cannot say whether it fails open or closed. It's probably impossible to determine whether any box's response to any failure will be pass or drop, with any reliability. All you can figure is probabilities. Given that most NATs only use a small set of address on the inside it is actually feasible to probe through a NAT using LSR. Most attacks don't do this as there are lots of lower hanging fruit but if it is a targeted attack then yes you can expect to see LSR based attacks which depending apon how the NAT is built may pass through it without even being noticed. Someone else has already addressed low-hanging fruit, so I won't. I do concur, though: if you have specific examples of boxes which, as you allege, respect LSR to 1918 internal addresses, please, name and shame. Why do they need to be named and shamed? They are NOT firewalls. It is not their job to block LSR traffic. The fact that you think NATs should be doing this is yet another indication that you don't understand the difference between a NAT and a firewall. Now can we put to bed that NAT provides any real security. If you want security add and configure a firewall. That firewall can be in the same box as the NAT. It can use the same state tables as the NAT but it is the firewall, not the NAT functionality, that provides the protection. Nope; I'm afraid we still can't. As long as you continue to strawman that I/we are even *alleging* that NAT provides security (rather than contributing to it, we're just going to keep talking past each other, Mark. As long as you keep defining protection as one thing in one place, I'll keep assuming you're flapping your jaws to dry your teeth. (provides *the* protection) Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.co m Designer The Things I Think RFC 210 0 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DI I St Petersburg FL USA http://photo.imageinc.us +1 727 647 127 4 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: OpenSource IPTV and VoD Solution
On Nov 14, 2011, at 10:25 PM, Meftah Tayeb wrote: thank you for that is a rtsp server no problem but how do i stream Live DVB traffic through it ? Thank you To be honest I haven't followed its development closely lately (although I contribute occasionally with networking related patches and improvements) so I can't answer that, but you should be able to send your stream to RTMPD using either MumuDVB or VLC, then demux it to as many (hundreds or even thousands, it is *that* good) clients as you need. I should have pointed you to the wiki [1] and the mailing list [2], sorry. HTH. [1] http://wiki.rtmpd.com/ [2] http://groups.google.com/group/c-rtmp-server?pli=1 -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com
FW: Savvis broken link / underperforming between DC and Atlanta?
All: I did not see a reply to this. Anyone else having a problem on this link? Lorell From: Lorell Hathcock [mailto:lor...@hathcock.org] Sent: Friday, November 11, 2011 9:10 AM To: nanog@nanog.org Subject: Savvis broken link / underperforming between DC and Atlanta? Any one else seeing this? This was done yesterday from Hawaii. tracert speedtest.saas.infor.com 3 5 ms 5 ms 4 ms ip64-75-240-210.aloha.net [64.75.240.210] 4 5 ms 5 ms 5 ms hnl-edge-02.inet.qwest.net [67.129.94.69] 5 *** Request timed out. 656 ms56 ms56 ms 63-235-40-18.dia.static.qwest.net [63.235.40.18] 758 ms58 ms59 ms cr1-tenge-0-3-5-0.sanfrancisco.savvis.net [204.70.200.198] 8 138 ms 138 ms 138 ms cr1-bundle-pos2.Washington.savvis.net [204.70.200.90] 9 135 ms 136 ms 136 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 10 139 ms 136 ms 137 ms 165.193.78.106 11 *** Request timed out. 12 *** Request timed out. 13 *** Request timed out. But from Houston it was fine yesterday. It took a different route. Today I have the same problem from Houston. tracert speedtest.saas.infor.com 4 2 ms 2 ms 2 ms te4-1.3509.ccr01.iah02.atlas.cogentco.com [66.28.6.21] 5 3 ms 2 ms 2 ms te0-2-0-4.ccr21.iah01.atlas.cogentco.com [154.54.3.149] 6 9 ms10 ms 8 ms te0-1-0-5.ccr21.dfw01.atlas.cogentco.com [154.54.2.225] 7 8 ms 8 ms 8 ms te7-3.mpd01.dfw03.atlas.cogentco.com [154.54.6.66] 815 ms 8 ms12 ms aer1-ge-4-2.dallasequinix.savvis.net [208.175.175.5] 917 ms 8 ms15 ms 204.70.207.182 1010 ms 9 ms10 ms cr1-tengig0-7-5-0.Dallas.savvis.net [204.70.200.170] 1137 ms37 ms37 ms cr1-tengig-0-7-0-0.Washington.savvis.net [204.70.196.105] 1236 ms36 ms36 ms hr1-tengig-2-0-0.sterling2dc2.savvis.net [204.70.197.74] 1337 ms36 ms37 ms 165.193.78.106 14 *** Request timed out. 15 *** Request timed out. 16 *** Request timed out. This the end IP address is in Rackspace in Atlanta I am told. Known issues out there? Any de-peering going on? Or is this just a firewall or private IP space that is not responding to traceroute information requests? Thanks for any help, Lorell Hathcock
Re: Minimum Allocation Size by RIRs (IPv4)
/24 as minimal allocation is only for end-users and critical infrastructure. For ISPs (LIRs) the minimal allocation is /22. /as On 16 Nov 2011, at 00:30, Rubens Kuhl wrote: LACNIC: /24 - http://lacnic.net/en/politicas/manual3.html
Question about operational concerns with Routing Protocol Security
Howdy, while enjoying some (oddly not controversial) meeting time at the IETF, one of the presenters (Sam Hartman[1]) noted he's looking for some people to chat with with respect to 'deployment scenarios' surrounding network gear and protocol security. Today that probably takes the form of things like: Hey, be sure to copy the password into the config before turning up the interfaces! I can imagine other methods as well, for things like: eBGP iBGP ISIS OSPF would any of the folks on-list that currently have key material (passwords and such) configured for these protocols AND who also deploy new gear into the field be willing to chat some with Sam? (Note, you don't have to tell Sam your passwds/keys, and you don't have to tell anyone else that the passwd is 'chocolate' either...) Thanks! -Chris (also, note that I copied in at least one of Sam's emails, maybe this one won't get too filtered...) [1]: The draft Sam could use some advice on: http://tools.ietf.org/id/draft-ietf-karp-ops-model-01.txt
Re: Foundry MRP cohabit with STP
MRP and STP are configured under VLAN, same physical interface tagged with different VLANs can participate both MRP and STP in different VLAN, if you are asking MRP and STP under the same VLAN, that is not a valid configuration, think about it, what if MRP wants to block an interface but STP wants the same interface to forward traffic? On Tue, Nov 15, 2011 at 1:30 AM, Viet-Hung Ton v...@integra.fr wrote: Hi, We are deploying a network using MRP of Foundry (Metro Ring Protocol of Brocade now) and STP (in this case Rapid Spanning Tree Protocol-802.1W). The problem is that in some networking segment, we must enable both of protocols in the same interfaces and vlans for the correct function of our network. By the way, as MRP and STP are 2 protocols of loop prevention, the devices of Brocade force us choosing and activating just one among them that not our intention. Anybody has the same situation of some experiences in this case: how to make coexist these two protocols. (MRP and STP). Best thanks, Viet Ton.
AS9929 - Anyone with Clue
Hi all. If there's anyone on here from AS9929 (Chine Netcom) with some clue, kindly ping me off-list. Thanks. Cheers, Mark. signature.asc Description: This is a digitally signed message part.
RE: OpenSource IPTV and VoD Solution
Hi, I don't know if it meets your requirements but there is DVBlast: http://www.videolan.org/projects/dvblast.html BRs, Quentin Carpent Network Engineer -Message d'origine- De : Vlad Galu [mailto:g...@packetdam.com] Envoyé : mercredi 16 novembre 2011 06:18 À : Meftah Tayeb Cc : nanog@nanog.org Objet : Re: OpenSource IPTV and VoD Solution On Nov 14, 2011, at 10:25 PM, Meftah Tayeb wrote: thank you for that is a rtsp server no problem but how do i stream Live DVB traffic through it ? Thank you To be honest I haven't followed its development closely lately (although I contribute occasionally with networking related patches and improvements) so I can't answer that, but you should be able to send your stream to RTMPD using either MumuDVB or VLC, then demux it to as many (hundreds or even thousands, it is *that* good) clients as you need. I should have pointed you to the wiki [1] and the mailing list [2], sorry. HTH. [1] http://wiki.rtmpd.com/ [2] http://groups.google.com/group/c-rtmp-server?pli=1 -- PacketDam: a cost-effective software solution against DDoS http://www.packetdam.com
