- NANOG - lists.nanog.org

Re:
by Joel Esler (jesler) 08 May '15

08 May '15

Seeing them here too. -- Joel Esler Sent from my iPhone On May 7, 2015, at 9:58 PM, Paul Ferguson via NANOG <nanog(a)nanog.org<mailto:nanog@nanog.org>> wrote: <mime-attachment>

1 0

Re: Missing Subjects
by Nathan Angelacos 08 May '15

08 May '15

Looks like there's an extra line break after this header line: X-Virus-Scanned: ClamAV using ClamSMTP So the SMTP headers are getting partitioned.

1 0

Re: Missing Subjects
by Nathan Angelacos 08 May '15

08 May '15

Looks like there's an extra line break after:

1 0

Re:
by Mike Hammett 08 May '15

08 May '15

I've seen the same over here and also considered it weird. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com ----- Original Message ----- From: "Paul Ferguson via NANOG" <nanog(a)nanog.org> To: "NANOG" <nanog(a)nanog.org> Sent: Thursday, May 7, 2015 8:56:44 PM

1 0

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