Re: Spam?

[Paul Graydon]

OMG can't you people run proper spam filtering on your own mail 
servers that filter out the nanog messages that are spam?!


I think I've had two messages in the last month, while others of you 
are talking about dozens?


Do you need to buy some hosting for your email accounts?


My filtering works great, thanks.  It's just that I'd whitelisted Nanog 
as a reliable source of e-mail.  Under the mailman setup where only 
subscribers were allowed to post that wasn't a problem.  With the new 
format it was and a good half dozen e-mails got through to me (I 
certainly didn't see dozens).  Does make me rather curious what the 
rejection stats are like for the old Mailman setup.


Paul

RE: OT: Given what you know now, if you were 21 again...

[Leigh Porter]

On 14/07/2011 9:08 a.m., Larry Stites wrote:
> Given what you know now, if you were 21 and just starting into networking /
> communications industry which areas of study or specialty would you
> prioritize?
>

Rebeccah Harris in my physics lectures. She was clearly up for it.

--
Leigh


__
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
__

Re: Spam?

[Richard Kulawiec]

On Thu, Jul 14, 2011 at 06:48:54PM +1200, Don Gould wrote:
> OMG can't you people run proper spam filtering on your own mail
> servers that filter out the nanog messages that are spam?!

One of the fundamental principles of spam mitigation is that blocking
is usually best (in terms of: efficacy, accuracy, resource minimization,
and other metrics) when applied as close to the source as possible.
In the case of mailing lists, such as this one, it has been a best practice
for many years to only permit traffic from subscribers (and optionally,
from individually-listed addresses, which are often alternate addresses
for subscribers).   It is clear that a serious mistake was made during
the attempted migration of this list, i.e., this best practice was not
followed, thus allowing some number of messages from non-subscribers to
reach some number of subscribers.  The proper solution to this is most
emphatically not to ask the thousands of NANOG subscribers to adjust
their mail systems; the proper solution is to continue to employ this
best practice.

---rsk

Re: NANOG List Update - Moving Forward

[Ben McGinnes]

On 13/07/11 11:37 PM, Richard Kulawiec wrote:
> On Tue, Jul 12, 2011 at 04:13:10PM +0200, Mattias Ahnberg wrote:
>> I might have missed some discussion; but why are we moving
>> away from mailman, and what software is in the new system?
> 
> Seconded.  Mailman is presently the gold standard for mailing list
> management

Apparently the main exception to this is where you're running multiple
lists with similar names, such as when creating lists for multiple
languages (e.g. annou...@example.com, annou...@it.example.com,
annou...@jp.example.com, etc.).  This is the problem the Document
Foundation found itself with and they opted for mlmmj (with the
exception of one list which does use Mailman), but it has other issues
and I definitely wouldn't want to see NANOG go down that path.  Since
NANOG doesn't need to deal with the similar names/multilingual
problem, that shouldn't be an issue.


Regards,
Ben



signature.asc
Description: OpenPGP digital signature

Re: NANOG List Update - Moving Forward

[Alex Ryu]

That issue can be resolved by changing email addresses for multiple
language support by using announce...@example.com,
anounce...@example.com ?

Alex


On Thu, Jul 14, 2011 at 8:57 AM, Ben McGinnes  wrote:
> On 13/07/11 11:37 PM, Richard Kulawiec wrote:
>> On Tue, Jul 12, 2011 at 04:13:10PM +0200, Mattias Ahnberg wrote:
>>> I might have missed some discussion; but why are we moving
>>> away from mailman, and what software is in the new system?
>>
>> Seconded.  Mailman is presently the gold standard for mailing list
>> management
>
> Apparently the main exception to this is where you're running multiple
> lists with similar names, such as when creating lists for multiple
> languages (e.g. annou...@example.com, annou...@it.example.com,
> annou...@jp.example.com, etc.).  This is the problem the Document
> Foundation found itself with and they opted for mlmmj (with the
> exception of one list which does use Mailman), but it has other issues
> and I definitely wouldn't want to see NANOG go down that path.  Since
> NANOG doesn't need to deal with the similar names/multilingual
> problem, that shouldn't be an issue.
>
>
> Regards,
> Ben
>
>

Re: NANOG List Update - Moving Forward

[Ben McGinnes]

On 15/07/11 12:24 AM, Alex Ryu wrote:
> That issue can be resolved by changing email addresses for multiple
> language support by using announce...@example.com,
> anounce...@example.com ?

Yeah, that's how I'd get around it.  I think the Document Foundation
had some other issues, like wanting addresses to be consistent across
a large number of subdomains and I can see their point with it.
Obviously it's not a case that NANOG has to deal with.


Regards,
Ben



signature.asc
Description: OpenPGP digital signature

NANOG - Call for Volunteers

[Michael K. Smith - Adhost]

Hello All:

Given the issues we had with the mailing list transition, we would like to 
solicit volunteers to assist in testing the "new" configuration.  Please note, 
we are just moving the existing Mailman configuration to a new server under our 
control, but we have to move the list due to contractual obligations.   Here's 
the basic scenario.

1) Build replica of existing NANOG Mailman server and configuration, except we 
are updating all of the underlying applications, including the actual OS.
2) Create a t...@mailtest.nanog.org mailing list
3) Have volunteers hammer the list and make sure the software setup is correct
4) Sync the existing list data to the new server
5) Flip DNS so that nanog@nanog.org is now served from the new server

If you are available and willing to assist in this test, please send me an 
email directly with the address you would like to use.  I will add you to the 
new list when the software is configured and you will receive the usual welcome 
message.  

Our timeline is tight for this transition; we have to be moved over to the new 
server no later than July 31st, so active testing and reporting is key.

Thank You,

Mike
--
Michael K. Smith - CISSP, GSEC, GISP
Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)

Enterprise Internet - Question

[Jeff Cartier]

Hi All,

I just wanted to throw a question out to the list...

In our data center we feed Internet to some of our US based offices and every 
now and again we receive complaints that they can't access some US based 
Internet content because they are coming from a Canadian based IP.

This has sparked an interesting discussion around a few questionsof which 
I'd like to hear the lists opinions on.

-  How should/can an enterprise deal with accessibility to internet 
content issues? (ie. that whole coming from a Canadian IP accessing US content)

o   Side question on that - Could we simply obtain a US based IP address and 
selectively NAT?

-  Does the idea of regional Internet locations make sense?  If so, 
when do they make sense?  For instance, having a hub site in South America (ie. 
Brazil) and having all offices in Venezuela, Peru and Argentina route through a 
local Internet feed in Brazil.

-  Does the idea of having local Internet at each site make more sense? 
 If so why?


Again, I would appreciate to hear the opinion from SP oriented minds...based on 
what they've seen from customers...and network administrators running large 
enterprises in different companies.  Off-list replies are also appreciated.

Thanks!!!

...jc




__
DISCLAIMER: This e-mail contains proprietary information some or all of which 
may be legally privileged.  It is for the intended recipient only. If an 
addressing or transmission error has misdirected this e-mail, please notify the 
author by replying to this e-mail.  If you are not the intended recipient you 
must not use, disclose, distribute, copy, print, or rely on this e-mail.

This message has been scanned for the presence of computer viruses, Spam, and 
Explicit Content.

Re: Enterprise Internet - Question

[Phil Sykes]

Hi Jeff,

You might have some luck following the instructions on
http://nanog.cluepon.net/index.php/GeoIP to register one particular /32
within your Canadian-announced netblock as being in the USA, and selectively
NATing as you suggest, but I believe some stricter GeoIP databases check
next hops and expected latency and might catch you out.

We're lucky enough to have proxies in most geographies where we operate, so
if a user has GeoIP issues we talk them through changing their proxy
settings (you could also use a personal PAC file).

(My employer's) principles in favour of a local internet breakout:

- Is breaking out to the internet locally significantly cheaper than
backhauling over private WAN (some MPLS providers will offer a local
internet breakout as a VRF; this avoids the need for two access circuits)
- Do you need to congest the internet traffic more than/independently to the
private WAN traffic?
- Would a tunnel over the internet be a useful backup to private circuits?
- Are there latency-related performance reasons (lots of local content) to
break out locally?
- Are there regulatory reasons? (e.g. Middle East / Chinese state-level
filtering)

Against local breakout:

- Do you need to limit the number of locations with an internet breakout
because you have a heavyweight security stack protecting an internet
connection (filtering proxy, IDS/IPS, multi-layer HA firewalls)?
- Is local internet of poor quality?

Regards,

Phil Sykes
Network Architect
$LARGE_OIL_COMPANY

On Thu, Jul 14, 2011 at 8:34 PM, Jeff Cartier <
jeff.cart...@pernod-ricard.com> wrote:

> Hi All,
>
> I just wanted to throw a question out to the list...
>
> In our data center we feed Internet to some of our US based offices and
> every now and again we receive complaints that they can't access some US
> based Internet content because they are coming from a Canadian based IP.
>
> This has sparked an interesting discussion around a few questionsof
> which I'd like to hear the lists opinions on.
>
> -  How should/can an enterprise deal with accessibility to internet
> content issues? (ie. that whole coming from a Canadian IP accessing US
> content)
>
> o   Side question on that - Could we simply obtain a US based IP address
> and selectively NAT?
>
> -  Does the idea of regional Internet locations make sense?  If so,
> when do they make sense?  For instance, having a hub site in South America
> (ie. Brazil) and having all offices in Venezuela, Peru and Argentina route
> through a local Internet feed in Brazil.
>
> -  Does the idea of having local Internet at each site make more
> sense?  If so why?
>
>
> Again, I would appreciate to hear the opinion from SP oriented
> minds...based on what they've seen from customers...and network
> administrators running large enterprises in different companies.  Off-list
> replies are also appreciated.
>
> Thanks!!!
>
> ...jc
>
>
>
>
> __
> DISCLAIMER: This e-mail contains proprietary information some or all of
> which may be legally privileged.  It is for the intended recipient only. If
> an addressing or transmission error has misdirected this e-mail, please
> notify the author by replying to this e-mail.  If you are not the intended
> recipient you must not use, disclose, distribute, copy, print, or rely on
> this e-mail.
>
> This message has been scanned for the presence of computer viruses, Spam,
> and Explicit Content.
>
>

Re: Enterprise Internet - Question

[Owen DeLong]

On Jul 14, 2011, at 12:34 PM, Jeff Cartier wrote:

> Hi All,
> 
> I just wanted to throw a question out to the list...
> 
> In our data center we feed Internet to some of our US based offices and every 
> now and again we receive complaints that they can't access some US based 
> Internet content because they are coming from a Canadian based IP.
> 
> This has sparked an interesting discussion around a few questionsof which 
> I'd like to hear the lists opinions on.
> 
> -  How should/can an enterprise deal with accessibility to internet 
> content issues? (ie. that whole coming from a Canadian IP accessing US 
> content)
> 

This is an example of why content restriction based on IP address geolocation 
is such a bad idea in general.

Frankly, the easiest thing to do (since most Canadian companies aren't as 
brain-dead) is to update your whois records with the address of the block
allocated to your datacenter so that it looks like it's in one of your US 
offices. I realize this sounds silly for a variety of reasons, but, it solves 
the problem
without expensive or configuration-intensive workarounds such as selective NAT, 
etc.

> o   Side question on that - Could we simply obtain a US based IP address and 
> selectively NAT?
> 
You can, but, you can also hit yourself over the head repeatedly with a hammer. 
Selective NAT will yield more content, but, the pain levels will probably be 
similar.

> -  Does the idea of regional Internet locations make sense?  If so, 
> when do they make sense?  For instance, having a hub site in South America 
> (ie. Brazil) and having all offices in Venezuela, Peru and Argentina route 
> through a local Internet feed in Brazil.
> 

Not really. The whole content-restriction by IP geolocation thing also doesn't 
make sense. Unfortunately, the fact that something is nonsensical does not 
prevent someone from doing it or worse, selling it.

You should do what makes sense for the economics of the topology you need. The 
address geolocation issues can usually be best addressed by manipulating whois. 
If your address block from ARIN is an allocation, you can manipulate sub-block 
address registration issues through the use of SWIP, for example.

> -  Does the idea of having local Internet at each site make more 
> sense?  If so why?
> 

That's really more of an economic and policy question within your organization 
than a technical one.
> 

Owen

Re: OT: Given what you know now, if you were 21 again...

[Jason Baugher]

On 7/13/2011 4:28 PM, Saku Ytti wrote:

On (2011-07-13 14:08 -0700), Larry Stites wrote:


Given what you know now, if you were 21 and just starting into networking /
communications industry which areas of study or specialty would you
prioritize?

Again? Buy AAPL, INTC and MSFT with loan money and study *cough*, finer things
in life.

But in all seriousness, networking like I suppose most professions are not
about knowing one thing and stopping. It's evolving rather rapidly so most
thing you know now are irrelevant in decade or two. What you should learn is
how to learn, how to attack problems and learn to love doing both.


+1

If I had to have a job where I did the same thing every day, year after 
year, I'd stab a pencil in my eye. I love that our industry is 
constantly evolving.


Jason

Re: Enterprise Internet - Question

[david raistrick]

On Thu, 14 Jul 2011, Jeff Cartier wrote:

- Does the idea of having local Internet at each site make more sense? 
If so why?


IME, costs for private backhaul circuits of any flavor are significantly 
higher than costs for plain internet access - so backhauling internet 
access (unless you have extremely restrictive access policies that you can 
actually enforce) through your WAN would/should cost through the nose. 
Routing only WAN traffic through the WAN reduces the size/scope/impact on 
those more expensive circuits.Probably at the expense of additional 
complexity, of course.





--
david raistrickhttp://www.netmeister.org/news/learn2quote.html
dr...@icantclick.org http://www.expita.com/nomime.html

Re: OT: Given what you know now, if you were 21 again...

[Chris Adams]

Once upon a time, Jason Baugher  said:
> If I had to have a job where I did the same thing every day, year after 
> year, I'd stab a pencil in my eye. I love that our industry is 
> constantly evolving.

Definate +1 to that.

I look at how my father's job has changed in his 49+ years; he's gone
from a hardware-in-the-loop simulator that took a room full of analog
computer (because digital computers weren't fast enough) to where
computers are small and powerful enough that they looked at running a
sim in real-time on the flying vehicle (as additional guidance
feedback).

I dont't think anyone can realistically say what the Internet will look
like 10 years from now, much less 50.  Pundits like to guess, but they
usually miss their "next year" predictions anyway. :-)

-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

Re: Enterprise Internet - Question

[Owen DeLong]

On Jul 14, 2011, at 2:35 PM, david raistrick wrote:

> On Thu, 14 Jul 2011, Jeff Cartier wrote:
> 
>> - Does the idea of having local Internet at each site make more sense? If so 
>> why?
> 
> IME, costs for private backhaul circuits of any flavor are significantly 
> higher than costs for plain internet access - so backhauling internet access 
> (unless you have extremely restrictive access policies that you can actually 
> enforce) through your WAN would/should cost through the nose. Routing only 
> WAN traffic through the WAN reduces the size/scope/impact on those more 
> expensive circuits.Probably at the expense of additional complexity, of 
> course.
> 
In fact, it is often more cost effective to multihome each site and use VPNs 
for your WAN.

Owen

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Fernando Gont]

On 07/11/2011 09:17 PM, Karl Auer wrote:
> I realise this is not "specific implementations" as you requested, but
> it seems to me that the problem is generic enough not to require that.
> 
> The attack is made possible by the design of the protocol, not any
> failing of specific implementations. Specific implementations need to
> describe what they've done about it (mitigation or prevention).

Vulnerability to this specific issues has a great deal to do with the
implementation. After all, whenever there's a data structure that can
potentially grow out of bounds (or hit a limit), it becomes a resource
management issue.

In this particular case, if the implementation enforces a limit on the
number of entries in the "INCOMPLETE" state, then only nodes that have
never communicated with the outside world could be affected by this
attack. And if those entries that are in the "INCOMPLETE" state are
pruned periodically (e.g. in a round-robin fashion), chances are that
even those "new hosts" would be able to get into the neighbor cache and
hence remain unaffected by this attack.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Jimmy Hess]

On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont  wrote:
> On 07/11/2011 09:17 PM, Karl Auer wrote:
> Vulnerability to this specific issues has a great deal to do with the
> implementation. After all, whenever there's a data structure that can
Yes

> In this particular case, if the implementation enforces a limit on the
> number of entries in the "INCOMPLETE" state, then only nodes that have
> never communicated with the outside world could be affected by this
> attack. And if those entries that are in the "INCOMPLETE" state are
> pruned periodically (e.g. in a round-robin fashion), chances are that

Not only that but  it's possible to differentiate _how_ an entry is added to
the table when the table reaches a "high water mark" it's possible
to drop the packet that was attempting to cause a NDP discover, fail to add
the INCOMPLETE entry to the table,  but _still_  send  the outgoing NDP
neighbor solicitation, and complete the entry or "whitelist"  the destination
if the neighbor advertises itself.

That is: if the destination is good, the neighbor will respond to the
NDP solicit,
even though the neighbor doesn't have an entry in the table.

So a small number of packets are lost at initial setup, due to the
attack,  but further
packets are unaffected,

So long as the attack does not overwhelm router CPU,  and  so long as the
INCOMPLETE entry high water mark is at a low enough level,
so there is still ample space in the table.


Even more sophisticated strategies may be available.

It should be possible to mitigate this, so long as the attack does not actually
originate from a neighbor on the same subnet as a router  IP interface on
an IPv6 subnet with sufficient number of IPs.

> even those "new hosts" would be able to get into the neighbor cache and
> hence remain unaffected by this attack.
>
> Thanks,

-- 
-JH

Re: in defense of lisp (was: Anybody can participate in the IETF)

[Randy Bush]

you want to give ops feedback to the ietf, well ...

i suggest a loc/id session at the next nanog, 20-30 mins each for
  LISP
  ILNP
  6296

where each is explained at an architectural level in some detail with
also a predeterimied list of questions such as "how does this address
loc/id separation, routing table scaling, incremental deployment, state
of implementation/testing, ..."

and then a half hour where someone sums up the similarities and
differences.

and someone writes it up.

randy

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Owen DeLong]

On Jul 14, 2011, at 6:24 PM, Jimmy Hess wrote:

> On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont  wrote:
>> On 07/11/2011 09:17 PM, Karl Auer wrote:
>> Vulnerability to this specific issues has a great deal to do with the
>> implementation. After all, whenever there's a data structure that can
> Yes
> 
>> In this particular case, if the implementation enforces a limit on the
>> number of entries in the "INCOMPLETE" state, then only nodes that have
>> never communicated with the outside world could be affected by this
>> attack. And if those entries that are in the "INCOMPLETE" state are
>> pruned periodically (e.g. in a round-robin fashion), chances are that
> 
> Not only that but  it's possible to differentiate _how_ an entry is added to
> the table when the table reaches a "high water mark" it's possible
> to drop the packet that was attempting to cause a NDP discover, fail to add
> the INCOMPLETE entry to the table,  but _still_  send  the outgoing NDP
> neighbor solicitation, and complete the entry or "whitelist"  the destination
> if the neighbor advertises itself.
> 
> That is: if the destination is good, the neighbor will respond to the
> NDP solicit,
> even though the neighbor doesn't have an entry in the table.
> 
> So a small number of packets are lost at initial setup, due to the
> attack,  but further
> packets are unaffected,
> 
> So long as the attack does not overwhelm router CPU,  and  so long as the
> INCOMPLETE entry high water mark is at a low enough level,
> so there is still ample space in the table.
> 
> 
> Even more sophisticated strategies may be available.
> 
> It should be possible to mitigate this, so long as the attack does not 
> actually
> originate from a neighbor on the same subnet as a router  IP interface on
> an IPv6 subnet with sufficient number of IPs.
> 
>> even those "new hosts" would be able to get into the neighbor cache and
>> hence remain unaffected by this attack.
>> 
>> Thanks,
> 
> -- 
> -JH

Very true. This is where Mr. Wheeler's arguments depart from reality. He's right
in that the problem can't be truly fixed without some very complicated code 
added
to lots of devices, but, it can be mitigated relatively easily and mitigation 
really
is good enough for most real world purposes.

Owen

Re: Enterprise Internet - Question

[Jimmy Hess]

On Thu, Jul 14, 2011 at 2:34 PM, Jeff Cartier
 wrote:
> -          How should/can an enterprise deal with accessibility to internet 
> content issues? (ie. that whole coming from a Canadian IP accessing US 
> content)
You indeed might feed traffic towards such "IP restricted" sites
through a transparent proxy server,
or policy NAT based on destination IP, reducing all traffic towards
those sites from "canadian"
ranges, to a pool of  source IP addresses.

Just to take a jab at absurd "content restriction" by IP methods, a reminder...
There's no such thing as a "US" IP address.   There's no such thing as
a Canadian IP address.

There are IPs delegated to network operators who have an AS in certain
countries,
but that is no proof of country of origin.

What "country" is an IP address located in when it is assigned to a
terminal server, VPN server,
or proxy server in country $X, and there are authorized users that  connect
from 16 different countries?

--
-JH

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Fernando Gont]

On 07/14/2011 10:24 PM, Jimmy Hess wrote:
>> In this particular case, if the implementation enforces a limit on the
>> number of entries in the "INCOMPLETE" state, then only nodes that have
>> never communicated with the outside world could be affected by this
>> attack. And if those entries that are in the "INCOMPLETE" state are
>> pruned periodically (e.g. in a round-robin fashion), chances are that
> 
> Not only that but  it's possible to differentiate _how_ an entry is added to
> the table when the table reaches a "high water mark" it's possible
> to drop the packet that was attempting to cause a NDP discover, fail to add
> the INCOMPLETE entry to the table,  but _still_  send  the outgoing NDP
> neighbor solicitation, and complete the entry or "whitelist"  the destination
> if the neighbor advertises itself.

Agreed. I should double-check whether there's room in the current
specifications to do this -- however, whether the specs allow this or
not is irrelevant. At the point you're being hit with a DoS, you better
do something about it (particularly when it's possible, as in this case!)


> That is: if the destination is good, the neighbor will respond to the
> NDP solicit,
> even though the neighbor doesn't have an entry in the table.

Modulo that when the high water mark has not been hit, the router should
probably *not* create ND cache entries in response to this "gratuitous"
ND advertisements, since otherwise it would open the door to a DoS from
local attackers.


> It should be possible to mitigate this, so long as the attack does not 
> actually
> originate from a neighbor on the same subnet as a router  IP interface on
> an IPv6 subnet with sufficient number of IPs.

Well, unless there's some layer-2 anti-spoofing mitigation in place,
with /64 subnets the "local attacker" typically *will* have enough
addresses.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Jared Mauch]

On Jul 14, 2011, at 10:06 PM, Fernando Gont  wrote:

>> It should be possible to mitigate this, so long as the attack does not 
>> actually
>> originate from a neighbor on the same subnet as a router  IP interface on
>> an IPv6 subnet with sufficient number of IPs.
> 
> Well, unless there's some layer-2 anti-spoofing mitigation in place,
> with /64 subnets the "local attacker" typically *will* have enough
> addresses.

Solving a local attack is something I consider different in scope than the 
current draft being discussed in 6man, v6ops, ipv6@ etc...

Anyone on a layer-2 network can do something interesting like flood all f's and 
kill the lan. Trying to keep the majority of thoughts here for layer-3 
originated attacks, even if the target is a layer2 item.

- Jared 

Re: Enterprise Internet - Question

[Owen DeLong]

On Jul 14, 2011, at 7:00 PM, Jimmy Hess wrote:

> On Thu, Jul 14, 2011 at 2:34 PM, Jeff Cartier
>  wrote:
>> -  How should/can an enterprise deal with accessibility to internet 
>> content issues? (ie. that whole coming from a Canadian IP accessing US 
>> content)
> You indeed might feed traffic towards such "IP restricted" sites
> through a transparent proxy server,
> or policy NAT based on destination IP, reducing all traffic towards
> those sites from "canadian"
> ranges, to a pool of  source IP addresses.
> 
> Just to take a jab at absurd "content restriction" by IP methods, a 
> reminder...
> There's no such thing as a "US" IP address.   There's no such thing as
> a Canadian IP address.
> 
> There are IPs delegated to network operators who have an AS in certain
> countries,
> but that is no proof of country of origin.
> 
> What "country" is an IP address located in when it is assigned to a
> terminal server, VPN server,
> or proxy server in country $X, and there are authorized users that  connect
> from 16 different countries?
> 
> --
> -JH

Yep And let us also not forget that people travel. Imagine my surprise
when I tried to log into Wells Fargo from Kigali and got the message that
"You have authenticated successfully, but, we don't trust your current
location. Everything will be fine when you log in from home."

Of course, I did the seemingly obvious thing and logged in from home.
Yeah, not so much. That got my account completely locked out and took
a 2.5 hour phone call (well, series of phone calls, maintaining a VOIP
connection from Kigali for that long wasn't happening) where I had
to escalate up three levels of support representative before reaching
someone who could understand what VNC was and that it was indeed
possible for me to control  my computer in the US from my laptop in
Kigali and that I had indeed legitimately logged in from both locations
about 2 minutes apart.

To the best of my knowledge, while this person reset my account so that
I could log in (from my house), I don't think Wells Fargo has any intention
of rethinking their geo-IP based restrictions on logging in.

So, if you travel, consider carefully whether to try and log into something
directly vs. doing so over VNC.

Owen

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Fernando Gont]

On 07/14/2011 11:35 PM, Jared Mauch wrote:

>> Well, unless there's some layer-2 anti-spoofing mitigation in
>> place, with /64 subnets the "local attacker" typically *will* have
>> enough addresses.
> 
> Solving a local attack

Well, I was talking about not *introducing* ;-) one.


> is something I consider different in scope
> than the current draft being discussed in 6man, v6ops, ipv6@ etc...

Which I-D are you referring to?

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Jared Mauch]

http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00

Sent from my iThing

On Jul 14, 2011, at 10:57 PM, Fernando Gont  wrote:

> On 07/14/2011 11:35 PM, Jared Mauch wrote:
> 
>>> Well, unless there's some layer-2 anti-spoofing mitigation in
>>> place, with /64 subnets the "local attacker" typically *will* have
>>> enough addresses.
>> 
>> Solving a local attack
> 
> Well, I was talking about not *introducing* ;-) one.
> 
> 
>> is something I consider different in scope
>> than the current draft being discussed in 6man, v6ops, ipv6@ etc...
> 
> Which I-D are you referring to?
> 
> Thanks,
> -- 
> Fernando Gont
> e-mail: ferna...@gont.com.ar || fg...@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Jimmy Hess]

On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch  wrote:
> On Jul 14, 2011, at 10:06 PM, Fernando Gont  wrote:
> Anyone on a layer-2 network can do something interesting like flood all f's 
> and kill the lan. Trying to keep the majority of thoughts here for layer-3 
> originated attacks, even if the target is a layer2 item.
> - Jared

In most cases if you have a DoS attack coming from the same Layer-2
network that a router is attached to,
it would mean there was already a serious security incident  that
occured to give the attacker that special point to attack from.

A similarly hazardous situation exists with IPv4,  and it is basically
unheard of  for IPv4's Layer 2/ARP security weaknesses to be exploited
to create a DoS condition, even though they can be (very easily),
IPv4  Layer 2 DoS conditions are often due to a malfunction or error
than intended attack;   more likely,   IPv6 Layer 2 security
weaknesses will be used to  intercept traffic for snooping, or quietly
subvert network policy.   LAN DoS conditions are noticed quickly, and
usually result in physical unplugging of the attacking  (or
malfunctioning)  node.

Methods can be designed to protect against spoofed NDP flooding on the
LAN that do not require the router's involvement.

For IPv4 switched networks there is a technology referred to as
'Dynamic ARP Inspection'.

Untrusted IPv6 LAN environments will need to implement SEND  or  some
form of  'Dynamic ND inspection'   plus RA-guard.

If it comes down to   solving a  remote DoS issue at the cost of
creating a LAN DoS issue that comes down to   'hosts on the LAN having
to spoof'

I would say that's easily well worth it.

--
-JH

Re: OT: Given what you know now, if you were 21 again...

[Daniël W . Crompton]

Hi Larry,

I would learn 2 things:
* having fun learning
* time management

It's been almost 14 years since I was 21 and I concur with many of the
things mentioned in this thread, and learned a few of them. However it
wasn't all the time I spend studying and learning, it's all the time I
spend being bored with studying that could have been easily solved
with a little patience and guidance on how to have fun learning. It
wasn't until I discovered the methods which were most effective for
learning a certain subject and keeping it fun.

Time management is another thing I would have wanted to start asap. So
I could have scheduled the procrastination and use the best parts of
the day to work or learn effectively.

my 2c
D.

On 13/07/2011, Larry Stites  wrote:
> Given what you know now, if you were 21 and just starting into networking /
> communications industry which areas of study or specialty would you
> prioritize?
>
>
> Thanks
>
>
>
> Larry Stites
> NCNetworks, Inc.
> Nevada City, CA 95959
>
>
>
>


-- 
blaze your trail

--
Daniël W. Crompton 




http://specialbrands.net/

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Fernando Gont]

On 07/15/2011 12:24 AM, Jimmy Hess wrote:

> A similarly hazardous situation exists with IPv4,  and it is basically
> unheard of  for IPv4's Layer 2/ARP security weaknesses to be exploited
> to create a DoS condition, even though they can be (very easily),

IMO, the situation is different, in that the typical IPv4 subnet size
eliminate some of the attack vectors.

For example, it would be virtually impossible for an ARP cache to grow
without bounds, and consume all kernel memory, because the typical IPv4
subnet size imposes a limit on the number of entries. That is *not* the
case with v6.


> IPv4  Layer 2 DoS conditions are often due to a malfunction or error
> than intended attack;   more likely,   IPv6 Layer 2 security
> weaknesses will be used to  intercept traffic for snooping, or quietly
> subvert network policy.   LAN DoS conditions are noticed quickly, and
> usually result in physical unplugging of the attacking  (or
> malfunctioning)  node.

Assuming the admin of the possibly-ipv6-enabled-by-default router is
IPv6 aware, etc.


> Methods can be designed to protect against spoofed NDP flooding on the
> LAN that do not require the router's involvement.

Which ones?




> For IPv4 switched networks there is a technology referred to as
> 'Dynamic ARP Inspection'.
> 
> Untrusted IPv6 LAN environments will need to implement SEND  or  some
> form of  'Dynamic ND inspection'   plus RA-guard.

Good luck with deploying SEND.

OTOH, forget about current implementations of RA-Guard:
* http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt
* http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt


> If it comes down to   solving a  remote DoS issue at the cost of
> creating a LAN DoS issue that comes down to   'hosts on the LAN having
> to spoof'
> 
> I would say that's easily well worth it.

You *can* fix the remote DoS issue, *without* introducing the
locally-exploitable one. That's the point.

Thanks,
-- 
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

Re: OT: Given what you know now, if you were 21 again...

[Joel Maslak]

On Wed, Jul 13, 2011 at 3:08 PM, Larry Stites  wrote:

> Given what you know now, if you were 21 and just starting into networking /
> communications industry which areas of study or specialty would you
> prioritize?
>

Make sure you are always learning.  You can't stop learning in this
industry.

Study the academic side of computers, not just how to use specific systems.
Know that systems other than the all-or-nothing superuser-based security
model exist, what a functional programming language is, basic computational
complexity, etc.  Unix or Cisco aren't always the best choices, but if you
don't know about the others you won't know that (FWIW, Cisco and Unix are
often excellent choices).

Learn to program reasonably well in at least a script language.

Learn TCP/IP.  It's going to be around for a while.  Focus on IPv4, but
expose yourself to IPv6.  This is probably the only specific
protocol/technology I'll mention.

Don't limit yourself to layer 3.  Learn about things like how to terminate
fiber optic cables and how application acceleration works.

Make sure you can write and speak well.

Learn when to shut up.  (I probably still haven't learned that one)

Learn how to get along with people, even ones that aren't as brilliant as
yourself.

Learn how to appropriately show accomplishment.  You don't want to be
arrogant, but you also don't want to be laid off because nobody knew that
you did great things.

Learn that people almost always have a reason for doing things the wrong
way, and it's best to find out what it is before you fix it!

This is probably controversial...Don't specialize religiously.  What I mean
about this is "don't become a Cisco guy."  Sure, you might become a Cisco
expert, and that's fine.  But don't lock yourself to a vendor or system
type.  Don't turn down a dream job that uses a different kind of router,
server, workstation, etc, just because you like Cisco (or whoever) better.
You won't want to use today's technology in a few years anyhow, so why make
long-term decisions based on hardware/software used today?  In the computer
field, even giants have fallen.

Learn that there is always someone smarter than you out there.  Learn from
them.

You have to start somewhere.  If you don't have good experience, you aren't
going to start at a (insert nice salary here) senior position, no matter how
much you know or what degree you have.  You might have to start on the night
shift of a NOC, making barely enough to eat, doing basic tasks.  Even in a
position like that, you can show you can learn - don't waste time while
working in these jobs, spend your free time learning, not playing computer
games or watching TV.  You'll get noticed.

Don't do illegal stuff.  It'll limit your options.  Pay your bills, don't do
drugs, don't get picked up for drunk driving, don't beat your significant
other.  These are the things that disqualify people with even basic
background checks - and many, many senior network jobs require a background
check.

Take opportunities.  Consider jobs where you'll have to learn a bit to be
effective - you might be the best person that applied.  But don't expect to
get jobs you aren't qualified for, and be honest about your abilities (but
confident).  Right now is a difficult time to get a job, even if you have
terrific qualifications.

Re: BGP Design question.

[Matt Hite]

Sure. Sometimes it's nice/convenient to let firewalls advertise the
external blocks they use for NAT translations, etc. Otherwise you need
to statically route them to the firewall and redistribute the statics
from said routers into your IGP.

Also, in some cases, people want to do network-based load balancing
(ECMP) to clusters of firewalls. So routing protocols obviously come
in handy with that.

Additionally, some people just want to avoid layer 2 clustering/HA
technologies whenever possible and prefer layer 3 HA solutions.

-M

On Wed, Jun 22, 2011 at 4:37 PM, -Hammer-  wrote:
> Do people really run routing protocols with their public address space on
> their FWs? I'm not saying right or wrong. Just curious. Seems like the last
> thing I would want to do would be to have my FW participate in a routing
> protocol unless is was absolutely necessary. Better to static the FW with a
> default route? I'd love to hear arguments for or against
>
> -Hammer-
>
>
>
> On 06/22/2011 06:33 PM, PC wrote:
>>
>> Who makes the firewall?
>>
>> To make this work and be "hitless", your firewall vendor must support
>> stateful replication of routing protocol data (including OSPF).  For
>> example, Cisco didn't support this in their ASA product until version 8.4
>> of
>> code.
>>
>> Otherwise, a failover requires OSPF to re-converge -- and quite frankly,
>> will likely cause some state of confusion on the upstream OSPF peers, loss
>> of adjacency, and a loss of routing until this occurs.  It's like someone
>> just swapped a router with the same IP  to the upstream device -- assuming
>> your active/standby vendor's implementation only presents itself as one
>> device.
>>
>> However, once this is succesful your current failover topology should work
>> fine -- even if it takes some time to failover.
>>
>> In my opinion though, unless the firewall is serving as "transit" to
>> downstream routers or other layer 3 elements, and you need to run OSPF to
>> it
>> (And through it) as a result, it's often just easier to static default
>> route
>> out from the firewall(s) and redistribute a static route on the upstream
>> routers for the subnets behind the firewalls.  It also helps ensure
>> symmetrical traffic flows, which is important for stateful firewalls and
>> can
>> become moderatly confusing when your firewalls start having many
>> interfaces.
>>
>>
>>
>>
>> On Wed, Jun 22, 2011 at 4:27 PM, Bret Palsson  wrote:
>>
>>
>>>
>>> Here is my current setup in ASCII art. (Please view in a fixed width
>>> font.)
>>> Below the art I'll write out the setup.
>>>
>>>
>>>     ++    ++
>>>     | Peer A |    | Peer A |<-Many carriers. Using 1 carrier
>>>     +---++    ++---+    for this scenario.
>>>         |eBGP          | eBGP
>>>         |              |
>>>     +---++iBGP++---+
>>>     | Router ++ Router |<-Netiron CERs Routers.
>>>     +-+--+    +--+-+
>>>       |A   `.P    A.'    |P<-A/P indicates Active/Passive
>>>       |      `.  .'      |      link.
>>>       |        ::        |
>>>     +-+--+'  `+--+-+
>>>     |Act. FW |    |Pas. FW |<-Firewalls Active/Passive.
>>>     ++    ++
>>>
>>>
>>> To keep this scenario simple, I'm multihoming to one carrier.
>>> I have two Netiron CERs. Each have a eBGP connection to the same peer.
>>> The CERs have an iBGP connection to each other.
>>> That works all fine and dandy. Feel free to comment, however if you think
>>> there is a better way to do this.
>>>
>>> Here comes the tricky part. I have two firewalls in an Active/Passive
>>> setup. When one fails the other is configured exactly the same
>>> and picks up where the other left off. (Yes, all the sessions etc. are
>>> actively mirrored between the devices)
>>>
>>> I am using OSPFv2 between the CERs and the Firewalls. Failover works just
>>> fine, however when I fail an OSPF link that has the active default route,
>>> ingress traffic still routes fine and dandy, but egress traffic doesn't.
>>> Both Netiron's OSPF are setup to advertise they are the default route.
>>>
>>> What I'm wondering is, if OSPF is the right solution for this. How do
>>> others solve this problem?
>>>
>>>
>>> Thanks,
>>>
>>> Bret
>>>
>>>
>>> Note: Since lately ipv6 has been a hot topic, I'll state that after we
>>> get
>>> the BGP all figured out and working properly, ipv6 is our next project.
>>> :)
>>>
>>>
>>>
>>>
>

Google DNS just disappeared

[Cody Rose]

Is anyone else seeing that Googles DNS records just disappeared?

I just lost all connectivity to Google services including google.com, 
plus.google.com, Public dns, etc.


Regards,
 
Cody Rose
NOC & Sys Admin
Website: www.killsudo.info 
email: c...@killsudo.info 

---
$ dig A google.com

; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>> A google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14667
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.IN  A

;; Query time: 4951 msec
;; SERVER: 10.168.88.7#53(10.168.88.7)
;; WHEN: Fri Jul 15 00:24:49 2011
;; MSG SIZE  rcvd: 28
---
$ dig  killsudo.info @8.8.8.8

; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>>  killsudo.info @8.8.8.8
;; global options: +cmd
;; connection timed out; no servers could be reached

$ dig  killsudo.info @208.67.222.222
---
; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>>  killsudo.info 
@208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29448
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;killsudo.info. IN  

;; ANSWER SECTION:
killsudo.info.  600 IN  2001:470:1f10:aa4::2

;; Query time: 63 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Fri Jul 15 00:29:55 2011
;; MSG SIZE  rcvd: 59


signature.asc
Description: This is a digitally signed message part.

Re: Google DNS just disappeared

[Cody Rose]

Service just returned,

DNS is active and connectivity directly to IPs are working again. Guess it was 
just a blip.

Regards,
 
Cody Rose
NOC & Sys Admin
Website: www.killsudo.info 
email: c...@killsudo.info 



signature.asc
Description: This is a digitally signed message part.

Re: Google DNS just disappeared

[Patrick W. Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jul 15, 2011, at 1:31 AM, Cody Rose wrote:

> Is anyone else seeing that Googles DNS records just disappeared?
> 
> I just lost all connectivity to Google services including google.com, 
> plus.google.com, Public dns, etc.


Weird, works fine from here (near Boston, MA, USA).  Tried from London & Tokyo, 
all three different ASNs.  Works fine everywhere I tried.

- -- 
TTFN,
patrick

TiggerBook-Air3:~ patrick$ dig www.google.com @8.8.8.8

; <<>> DiG 9.6.0-APPLE-P2 <<>> www.google.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52148
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.IN  A

;; ANSWER SECTION:
www.google.com. 86341   IN  CNAME   www.l.google.com.
www.l.google.com.   241 IN  A   74.125.93.104
www.l.google.com.   241 IN  A   74.125.93.99
www.l.google.com.   241 IN  A   74.125.93.106
www.l.google.com.   241 IN  A   74.125.93.105
www.l.google.com.   241 IN  A   74.125.93.147
www.l.google.com.   241 IN  A   74.125.93.103

;; Query time: 50 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jul 15 01:35:15 2011
;; MSG SIZE  rcvd: 148



> ---
> $ dig A google.com
> 
> ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>> A google.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14667
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;google.com.IN  A
> 
> ;; Query time: 4951 msec
> ;; SERVER: 10.168.88.7#53(10.168.88.7)
> ;; WHEN: Fri Jul 15 00:24:49 2011
> ;; MSG SIZE  rcvd: 28
> ---
> $ dig  killsudo.info @8.8.8.8
> 
> ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>>  killsudo.info @8.8.8.8
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> 
> $ dig  killsudo.info @208.67.222.222
> ---
> ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-7.P4.fc15 <<>>  killsudo.info 
> @208.67.222.222
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29448
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;killsudo.info. IN  
> 
> ;; ANSWER SECTION:
> killsudo.info.  600 IN  2001:470:1f10:aa4::2
> 
> ;; Query time: 63 msec
> ;; SERVER: 208.67.222.222#53(208.67.222.222)
> ;; WHEN: Fri Jul 15 00:29:55 2011
> ;; MSG SIZE  rcvd: 59

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAk4f0jgACgkQznMLL4aoth8rkwCgtlE2haybIdLS1Xdaq9lQa7ir
tFgAnjmwGYt57pYAVDh9Yr+1PPq/XEzX
=rMVR
-END PGP SIGNATURE-

Re: Google DNS just disappeared

[Cody Rose]

It appeared to be very brief, I just happened to be in a Google Plus Hangout 
when the chat died then my Gtalk died followed by my Google homepage.

By the time I got done checking DNS and was getting on a trace-route server my 
chat reconnected and  service was back to normal.

Just thought it was unusual to see all my Google services go offline at the 
same 
time.

Regards,
 
Cody Rose
NOC & Sys Admin
Website: www.killsudo.info 
email: c...@killsudo.info 



signature.asc
Description: This is a digitally signed message part.

Re: NDP DoS attack (was Re: Anybody can participate in the IETF (Was: Why is IPv6 broken?))

[Owen DeLong]

On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote:

> On Thu, Jul 14, 2011 at 9:35 PM, Jared Mauch  wrote:
>> On Jul 14, 2011, at 10:06 PM, Fernando Gont  wrote:
>> Anyone on a layer-2 network can do something interesting like flood all f's 
>> and kill the lan. Trying to keep the majority of thoughts here for layer-3 
>> originated attacks, even if the target is a layer2 item.
>> - Jared
> 
> In most cases if you have a DoS attack coming from the same Layer-2
> network that a router is attached to,
> it would mean there was already a serious security incident  that
> occured to give the attacker that special point to attack from.
> 
That's one possibility.

The other likely possibility is that you are a University.

Owen