Re: Automatic IPv6 due to broadcast
Hi, On Mon, Apr 23, 2012 at 12:27:53PM -0400, valdis.kletni...@vt.edu wrote: > On Mon, 23 Apr 2012 11:23:14 -0400, Chuck Anderson said: > > > On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: > >> In a lot of cases, enforcing that all address assignments are via DHCP can > >> still be > >> counter-productive. Especially in IPv6. > > If a specific managed environment provides DHCPv6 and doesn't provide > > SLAAC, and the policies of said environment forbid static addressing, > > That's totally different from Owen's "in a lot of cases". Incidentally, > there's absolutely nothing except for LLT being the default DUID generation mechanism on pretty much every OS... thanks Enno preventing a DHCPv* server from being configured to > always hand out the same IP address to a given MAC address, making it > effectively static (in fact, I've seen more than one site that carries nailed > down > DHCP entries for servers, just to ensure that even if the server gets borked > and > decides to DHCP itself, it will still come up with the "right" address > anyhow). > > > how can enforcing the use of DHCPv6 be counter-productive? > > Remember, Owen was talking about "in a lot of cases". I suspect Owen was > saying > that if you enforce that all source addresses are ones that the DHCPv6 server > handed out, you just broke a host that tries to do RFC4941 addresses or other > similar things. > -- Enno Rey ERNW GmbH - Breslauer Str. 28 - 69124 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474 PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey === Blog: www.insinuator.net || Conference: www.troopers.de ===
Re: Automatic IPv6 due to broadcast
On Mon, 23 Apr 2012 11:23:14 -0400, Chuck Anderson said: > > On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: >> In a lot of cases, enforcing that all address assignments are via DHCP can >> still be >> counter-productive. Especially in IPv6. > If a specific managed environment provides DHCPv6 and doesn't provide > SLAAC, and the policies of said environment forbid static addressing, That's totally different from Owen's "in a lot of cases". Incidentally, there's absolutely nothing preventing a DHCPv* server from being configured to always hand out the same IP address to a given MAC address, making it effectively static (in fact, I've seen more than one site that carries nailed down DHCP entries for servers, just to ensure that even if the server gets borked and decides to DHCP itself, it will still come up with the "right" address anyhow). > how can enforcing the use of DHCPv6 be counter-productive? Remember, Owen was talking about "in a lot of cases". I suspect Owen was saying that if you enforce that all source addresses are ones that the DHCPv6 server handed out, you just broke a host that tries to do RFC4941 addresses or other similar things. pgpLMLBQc34zB.pgp Description: PGP signature
Re: Automatic IPv6 due to broadcast
On Apr 23, 2012, at 8:23 AM, Chuck Anderson wrote: > On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: >> >> On Apr 23, 2012, at 6:25 AM, Chuck Anderson wrote: >> >>> On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote: On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: > Particularly good L2 switches also have > DAI or "IP Source guard" IPv4 functions, which when properly > enabled, can foil certain L2 ARP and IPv4 source address spoofing > attacks, respectively. > > e.g. Source IP address of packet does not match one of the DHCP leases > issued to that port -- then drop the packet. > Meh... I can see many cases where that might be more of a bug than feature. Especially in environments where loops may be possible and the DHCP lease might have come over a different path than the port in question during some network event. >>> >>> You're only supposed to use those features on the port directly >>> connected to the end-system, or to a few end-systems via an unmanaged >>> office switch that doesn't have redundant uplinks. I.e. edge ports. >> >> In a lot of cases, enforcing that all address assignments are via DHCP can >> still be >> counter-productive. Especially in IPv6. > > If a specific managed environment provides DHCPv6 and doesn't provide > SLAAC, and the policies of said environment forbid static addressing, > how can enforcing the use of DHCPv6 be counter-productive? That's a lot of ifs. I said in a lot of cases. I didn't say in all cases. If you satisfy all of your ifs, then it's not one of the cases of which I speak. Owen
Re: Automatic IPv6 due to broadcast
On Mon, Apr 23, 2012 at 06:38:09AM -0700, Owen DeLong wrote: > > On Apr 23, 2012, at 6:25 AM, Chuck Anderson wrote: > > > On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote: > >> On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: > >>> Particularly good L2 switches also have > >>> DAI or "IP Source guard" IPv4 functions, which when properly > >>> enabled, can foil certain L2 ARP and IPv4 source address spoofing > >>> attacks, respectively. > >>> > >> > >>> e.g. Source IP address of packet does not match one of the DHCP leases > >>> issued to that port -- then drop the packet. > >>> > >> > >> Meh... I can see many cases where that might be more of a bug than feature. > >> > >> Especially in environments where loops may be possible and the DHCP lease > >> might > >> have come over a different path than the port in question during some > >> network event. > > > > You're only supposed to use those features on the port directly > > connected to the end-system, or to a few end-systems via an unmanaged > > office switch that doesn't have redundant uplinks. I.e. edge ports. > > In a lot of cases, enforcing that all address assignments are via DHCP can > still be > counter-productive. Especially in IPv6. If a specific managed environment provides DHCPv6 and doesn't provide SLAAC, and the policies of said environment forbid static addressing, how can enforcing the use of DHCPv6 be counter-productive?
Re: Securing OOB
My preferred OOB solution is cellular where possible. (Many companies make such a dedicated product, or roll your own). Most cellular providers can provide a private APN with private IP addresses delivered back to you via a VPN tunnel. In many cases, telemetry (IE: 50Mb or less per month) data plans cost much less than DSL lines or analog lines. In some installations, it's also diverse to backhoe accidents due to it not riding the same copper bundle. Besides, it's easy to install and you don't have to deal with the copper analog handoff. Otherwise... DSL and IPSEC vpn also works. Analog is in the last option for me. On Mon, Apr 23, 2012 at 7:31 AM, Saku Ytti wrote: > On (2012-04-23 12:45 +), Leigh Porter wrote: > > > I have juniper SRX110s that use the magic new multi site IPSec thing. > > +1. This is the way to roll OOB, CPE (Cisco ISR, Juniper SRX), RS232 > console server (opengear, avocent) and switch if you happen to have modern > gear which support proper OOB like Nexus7k, and not enough ports in the > CPE. > OOB CPE could be reused for other functions to justify cost, like DCN > router, both SRX and ISR have models doing CLNS routing. > > With correct CPE, same CPE can do 3G, ADSL and ethernet, depending on what > is available in given site. > Some RS232 console servers do deliver subset of needed features, like 3G, > IPSEC and Ethernet might be there. But that does not mean that it'll be > OPEX nor CAPEX chaper to try to do it all in one box. > > -- > ++ytti > >
Re: Automatic IPv6 due to broadcast
On Apr 23, 2012, at 6:25 AM, Chuck Anderson wrote: > On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote: >> On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: >>> Particularly good L2 switches also have >>> DAI or "IP Source guard" IPv4 functions, which when properly >>> enabled, can foil certain L2 ARP and IPv4 source address spoofing >>> attacks, respectively. >>> >> >>> e.g. Source IP address of packet does not match one of the DHCP leases >>> issued to that port -- then drop the packet. >>> >> >> Meh... I can see many cases where that might be more of a bug than feature. >> >> Especially in environments where loops may be possible and the DHCP lease >> might >> have come over a different path than the port in question during some >> network event. > > You're only supposed to use those features on the port directly > connected to the end-system, or to a few end-systems via an unmanaged > office switch that doesn't have redundant uplinks. I.e. edge ports. In a lot of cases, enforcing that all address assignments are via DHCP can still be counter-productive. Especially in IPv6. Owen
Re: Securing OOB
On (2012-04-23 12:45 +), Leigh Porter wrote: > I have juniper SRX110s that use the magic new multi site IPSec thing. +1. This is the way to roll OOB, CPE (Cisco ISR, Juniper SRX), RS232 console server (opengear, avocent) and switch if you happen to have modern gear which support proper OOB like Nexus7k, and not enough ports in the CPE. OOB CPE could be reused for other functions to justify cost, like DCN router, both SRX and ISR have models doing CLNS routing. With correct CPE, same CPE can do 3G, ADSL and ethernet, depending on what is available in given site. Some RS232 console servers do deliver subset of needed features, like 3G, IPSEC and Ethernet might be there. But that does not mean that it'll be OPEX nor CAPEX chaper to try to do it all in one box. -- ++ytti
Re: Automatic IPv6 due to broadcast
On Mon, Apr 23, 2012 at 12:24:53AM -0700, Owen DeLong wrote: > On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: > > Particularly good L2 switches also have > > DAI or "IP Source guard" IPv4 functions, which when properly > > enabled, can foil certain L2 ARP and IPv4 source address spoofing > > attacks, respectively. > > > > > e.g. Source IP address of packet does not match one of the DHCP leases > > issued to that port -- then drop the packet. > > > > Meh... I can see many cases where that might be more of a bug than feature. > > Especially in environments where loops may be possible and the DHCP lease > might > have come over a different path than the port in question during some network > event. You're only supposed to use those features on the port directly connected to the end-system, or to a few end-systems via an unmanaged office switch that doesn't have redundant uplinks. I.e. edge ports.
RE: Securing OOB
Thanks for starting this discussion Eric. We're just starting to look at upgrading our oob console network and wondering how to provide access from LAN based application monitoring platforms. We're currently looking at installing a VPN appliance between our production network and the "oob network". -Steve -Original Message- From: Eric [mailto:e...@roxanne.org] Sent: Monday, April 23, 2012 8:40 AM To: nanog@nanog.org Subject: Securing OOB Hello, It seems that the current practice is to use a DSL line, as opposed to a modem, for accessing an OOB a console server at a remote colo. From a security standpoint, what do people generally do - trust the console server, repurpose an old linksys box from my house or put in a full firewall? Eric :)
Re: Securing OOB
On Mon, Apr 23, 2012 at 8:40 AM, Eric wrote: > Hello, > > It seems that the current practice is to use a DSL line, as opposed to a > modem, for accessing an OOB a console server at a remote colo. From a > security standpoint, what do people generally do - trust the console server, > repurpose an old linksys box from my house or put in a full firewall? > > Eric :) There are hardware solutions for this type of install. Often it is best to add/create networks for access from multiple points at once. My suggestion is http://www.lantronix.com/it-management/branch-office/securelinx-slb.html -- ~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~
Re: Securing OOB
I have juniper SRX110s that use the magic new multi site IPSec thing. -- Leigh Porter On 23 Apr 2012, at 13:43, "Eric" wrote: > Hello, > > It seems that the current practice is to use a DSL line, as opposed to a > modem, for accessing an OOB a console server at a remote colo. From a > security standpoint, what do people generally do - trust the console server, > repurpose an old linksys box from my house or put in a full firewall? > > Eric :) > > > > __ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Securing OOB
Hello, It seems that the current practice is to use a DSL line, as opposed to a modem, for accessing an OOB a console server at a remote colo. From a security standpoint, what do people generally do - trust the console server, repurpose an old linksys box from my house or put in a full firewall? Eric :)
Re: Automatic IPv6 due to broadcast
On Apr 22, 2012, at 10:30 PM, Jimmy Hess wrote: > On 4/22/12, Grant Ridder wrote: > >> Most switches nowadays have dhcpv4 detection that can be enabled for port > > Yes. Many L2 switches have DHCPv4 "Snooping", where some port(s) can > be so designated as trusted DHCP server ports, for certain Virtual > LANs; and dhcp messages can be detected and suppressed from > unauthorized edge ports. Sounds suspiciously like IPv6 RA Guard, no? > Particularly good L2 switches also have > DAI or "IP Source guard" IPv4 functions, which when properly > enabled, can foil certain L2 ARP and IPv4 source address spoofing > attacks, respectively. > > e.g. Source IP address of packet does not match one of the DHCP leases > issued to that port -- then drop the packet. > Meh... I can see many cases where that might be more of a bug than feature. Especially in environments where loops may be possible and the DHCP lease might have come over a different path than the port in question during some network event. > > As for IPv6; rfc6105; you have > ipv6 nd raguard > > and IOS NDP inspection. > > However, there are caveats that should be noted.RA guard > implementations can be trivially fooled by the use of crafted packets. > Frankly, I suggest dropping any RA that doesn't fit in a single packet as a simple solution to the crafted-packet issue. (The crafted packet attacks by and large depend on crafting it so that there are enough extension headers to put the RA header in the second or later fragment). > These are potentially good protections against accidental > configuration errors, but not malicious attack from a general purpose > computer. If you have a malicious attack from a general purpose computer on your own LAN, you've already lost on multiple levels to some extent or other. The most effective solution at that point is to identify, locate, and excise said attacker. > > > Currently, IPv4 seems to win at L2 easily in regards to the level of > hardware security features commonly available on L2 switches that > pertain to IP. > There was a time when one probably could have argued that Novell beat IP on that basis alone. IPv4 loses when you consider that there are more than 3.2 billion people in the world. That people likely will need a minimum of 5 IP addresses each. That we also need to number infrastructure, routers, servers, sensor grids, etc. IPv4 also loses when you consider the pervasiveness of debilitated IPv4 internetworking in favor of address conservation over the last 20 years. Owen > > >> -Grant > -- > -JH
