- Test - lists.nanog.org

List hiccups?
by Paul Ferguson 08 May '15

08 May '15

1 0

Re: Network Segmentation Approaches
by Scott Weeks 07 May '15

07 May '15

From: Rich Kulawiec <rsk(a)gsp.org> On Wed, May 06, 2015 at 03:30:01PM -0700, Scott Weeks wrote: > From: Rich Kulawiec <rsk(a)gsp.org> > > The first rule in every firewall is of course > "deny all" and subsequent rulesets permit only > the traffic that is necessary. > ------------------------------------ > > I think you got this backward? That way all > traffic is blocked, so none is allowed through. Nope, I said exactly what I intended (and what I do, in practice). Doing so forces one to understand in detail what traffic actually needs to pass in/out and to craft specific rules for it. This in turn helps avoid making mistake #1: The Six Dumbest Ideas in Computer Security http://www.ranum.com/security/computer_security/editorials/dumb/ ----------------------------------------------------- After reading your emails all these years, I figured you meant it the way you wrote it. When you wrote "...subsequent rulesets permit only the traffic that is necessary" I misunderstood and thought you meant rules put in after the default deny, which are useless. But by subsequent rulesets you meant rule sets put in later in time and above the deny all not after the deny all. Small confusion over wording... :-) scott

3 2

disadvantages of peering with own IP transit customers
by Martin T 07 May '15

07 May '15

Hi, what are the disadvantages of peering(announcing own and all customers prefixes) with own IP transit customers? One disadvantage is obviously that amount of traffic on IP transit link is lower and thus customer pays for smaller amount of Mbps. On the other hand, this can be somewhat compensated with higher price per Mbps if the amount of traffic on the IP transit connection is lower. However, are there any other disadvantages/concerns when peering with own IP transit customers? regards, Martin

3 2

link avoidance
by Randy Bush 07 May '15

07 May '15

a fellow researcher wants > to make the case that in some scenarios it is very important for a > network operator to be able to specify that traffic should *not* > traverse a certain switch/link/group of switches/group of links > (that's true right?). Could you give some examples? Perhaps point > me to relevant references? if so, why? security? congestion? other? but is it common? and, if so, how do you do it? randy

8 7

Re: Network Segmentation Approaches
by Scott Weeks 07 May '15

07 May '15

On 07.05.2015 08:30, Scott Weeks wrote: > --- rsk(a)gsp.org wrote: > From: Rich Kulawiec <rsk(a)gsp.org> > > The first rule in every firewall is of course > "deny all" and subsequent rulesets permit only > the traffic that is necessary. > ------------------------------------ > > > I think you got this backward? That way all > traffic is blocked, so none is allowed through. > Also, deny by default at the end of the rule > set is not the best thing for every network > that needs a firewall. Some just want to block > bad stuff they see and allow everything else. > (And some have stated here that they will block > entire countries until their culture changes!) --------------------------------------- --- aj(a)jonesy.com.au wrote: From: Andrew Jones <aj(a)jonesy.com.au> It depends on the software used and implementation. Many rulesets for pf on BSD start with 'block in on interfaceX' for instance, because it uses a "last match wins" system, unless you use the 'quick' keyword to make rule processing stop if that rule matches. ----------------------------------------- I was assuming stop looking on first match. So, "deny ip any any" blocks everything at the very beginning. scott

1 0

Question about co-lo in APAC region
by c b 07 May '15

07 May '15

This is a pre-project discovery question... any help would be greatly appreciated. We have upcoming partnerships (opportunities) in APAC. The original plan was to place the hub in Singapore. Just weeks before everyone was ready to begin the RFP, it turns out that one of our partner businesses owns a Co-Lo in India. Not sure what the name or the size of this business is yet. While it would be nice to take advantage of this, we have potential partnerships in China and other areas of APAC in development... we are hesitating to put our APAC hub in India just based on latency and where the undersea cables run. So, I'm reaching out to NANOG... some of you guys have either worked with businesses (or work in provider space) in both India and Singapore (and elsewhere, such as Japan). Is there a clear reason to use/not-use India as a hub? What would the pros/cons be? Is there a clear advantage to using Singapore as we originally planned? Again, we appreciate the feedback. LFoD

5 4

Re: Network Segmentation Approaches
by Scott Weeks 06 May '15

06 May '15

--- rsk(a)gsp.org wrote: From: Rich Kulawiec <rsk(a)gsp.org> The first rule in every firewall is of course "deny all" and subsequent rulesets permit only the traffic that is necessary. ------------------------------------ I think you got this backward? That way all traffic is blocked, so none is allowed through. Also, deny by default at the end of the rule set is not the best thing for every network that needs a firewall. Some just want to block bad stuff they see and allow everything else. (And some have stated here that they will block entire countries until their culture changes!) scott

3 2

Re: Alcatel-Lucent 7750 Service Router (SR)
by Scott Weeks 06 May '15

06 May '15

--- colton.conor(a)gmail.com wrote: From: Colton Conor <colton.conor(a)gmail.com> Why is ALU never mentioned, but Juniper MX and Cisco are all day long? ----------------------------------------- Because they're really expensive, mostly bell head networks use them and we're mostly bell head free on NANOG... >;-) scott

1 0

Re: Alcatel-Lucent 7750 Service Router (SR)
by Scott Weeks 06 May '15

06 May '15

> On May 6, 2015, at 5:48 PM, Colton Conor <colton.conor(a)gmail.com> wrote: > > I was wondering if anyone was using a > Alcatel-Lucent 7750 Service Router> (SR) > in their network? How does this platform > compare the the Cisco ASR, Brocade MLXe, > and Juniper MX line? --------------------------------- I haven't used them for nearly 5 years now, but at the time they were really good. Likely, they're still the same. Search the NANOG archives, there have been discussions before. Pay attention to the after the sale service stuff in the archives. Also Jared Mauch has a ML for them at puck.nether.net, but it's a really low volume list. ALU engineers hang out there. scott

1 0

Network Segmentation Approaches
by nanog1＠roadrunner.com 06 May '15

06 May '15

Possibly a bit off-topic, but curious how all of you out there segment your networks. Corporate/business users, dependent services, etc. from critical data and/or processes with remote locations thrown in the mix which could be mini-versions of your primary network. There's quite a bit of literature out there on this, so have been considering an approach with zones based on the types of data or processes within them. General thoughts: - "Business Zone" - This would be where workstations live, web browsing occurs, VoIP and authentication services live too. Probably consider this a somewhat "dirty" zone, but I should generally be OK letting anything in this zone talk fairly unfettered to anything else in this zone (for example a business network at my HQ location should be able to talk unfettered to an equivalent network at a remote site). I'd probably have VoIP media servers in this zone, AD, DNS, etc. - Some sort of management zone(z) - Maybe accessible only via jump host -- this zone gives "control" access into key resources (most likely IT resouces like network devices, storage devices, etc.). Should have sound logging/auditing here to establish access patterns outsid the norm and perhaps multi-factor authentication (and of course FW's). - Secure Zone(s) - Important data sets or services can be isolated from untrusted zones here. May need separate services (DNS, AD, etc.) - I should think carefully about where I stick stateful FW's -- especially on my internal networks. Risk of DoS'ing myself is high. Presumably I should never allow *outbound* connectivity from a more secure zone to a less secure zone, and inbound connectivity should be carefully monitored for unusual access patterns. Perhaps some of you have some fairly simple rules of thumb that could be built off of? I'm especially interested to hear how VoIP/RTP traffic is handled between subnets/remote sites within a "Business Zone". I'm loathe to put a FW between these segments as it will put VoIP performance at risk (maybe QoS on FW's can be pretty good), but maybe some sort of passive monitoring would make sense. (Yes, I've also read the famous thread on stateful firewalls[1]). Thanks! [1] http://markmail.org/thread/fvordsbnuc74fuu2#query:+page:1+mid:fvordsbnuc74f…

10 9