-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Missing a tag in the trigger is why you put the Murphy Filters in the
trigger router's route-map (the point you were getting at but being even
more explicit).
In my route map on the trigger router, I would not allow any static
route triggers
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Steven M. Bellovin
How about state-of-the-art routing security?
Seriously -- a number of us have been warning that this could happen.
More precisely, we've been warning that this could happen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There have been two or three panels on this exact topic in
the past, you can find them in the index of talks.
Unfortunately, the problem hasn't changed at all. Perhaps we
could just replay those video streams :-)
My $.02 -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Reposted with author's permission.]
+ Notice that there are more issues than what is reported in the
popular press.
+ Notice that there are issues with more submarine systems (APCN),
but they are not news.
As has been pointed out before, there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
anyway, the idea behind multi-as blackholing has been (and
apparently continues to get) rehashed a few times over the
last 5-8 years... good luck!
It seems that way. People seem to forget about the conversations and
work around 2000 -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Check out:
http://www.nanog.org/mtg-0302/cidr.html
I still think the CIDR Report only has a impact if you have a team of
volunteers knocking people on the side of the head and getting them
to pay attention. People look at the top, but try looking
http://www.completewhois.com/hijacked/files/203.27.251.0.txt
http://www.completewhois.com/hijacked/index.htm
This can proof the opposite.
Malware comes from redirected allocated blocks, not from bogons.
I don't think this is proof. The haphazard way that BCP38 and ingress
prefix
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Chris L. Morrow
Sent: Thursday, March 01, 2007 6:23 AM
To: Jon Lewis
Cc: Eric Ortega; nanog@merit.edu
Subject: Where are static bogon filters appropriate? was:
96.2.0.0/16 Bogons
On Thu, 1
- We have this source:
http://www.iana.org/assignments/ipv4-address-space
- We source URLs for each of the RIRs in the prefix filter templates:
ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Template
s/
Postings like this to NANOG will not have any impact. So if your goal is
instigate action, posting is not going to work. The core data point is
the weekly CIDR report. It only works if you have peers using the weekly
list to apply peer pressure to the networks listed to act.
Sharing summaries
It was possible to implement BCP38 before the router
vendors came up
with uRPF.
Further, uRPF is frequently a very inefficient means of
implementing
BCP 38. Consider that you're going to either compare the source
address against a table of 200,000 routes or against a
What? That's what I'm trying to find out, but I'm not as
smart as most, so I can only point out the things that I
believe definitely won't work and why I think that.
Hopefully by the application of flame to my butt by smart
people for saying what I do will spark some thought toward
Anycast - it is a widget - not a solution.
Go here http://www.nanog.org/subjects.html, look for Anycast, and watch
the VODs.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Robert Sherrard
Sent: Tuesday, August 01, 2006 5:54 PM
To:
This RFC1918 for control plane/management plane technique is
vulnerable to a TCP reflection attack. The miscreants know about it. So
the assumption that the chance of a RFC 1918 packet reaching your router
being zero is not something an you should assume.
-Original Message-
From:
for TCP-MD5
On Fri, Jun 23, 2006 at 11:49:33AM -0700, Barry Greene
(bgreene) wrote:
Yes Jared - our software does the TTL after the MD5, but
the hardware
implementations does the check in hardware before the packet gets
punted to the receive path. That is exactly where you
hardware we've got deployed
today - not wishing the community would just upgrade.
-Original Message-
From: Bora Akyol [mailto:[EMAIL PROTECTED]
Sent: Friday, June 23, 2006 2:02 PM
To: [EMAIL PROTECTED]
Cc: Barry Greene (bgreene); Ross Callon; nanog@merit.edu
Subject: RE: key change
Why couldn't the network device do an AH check in hardware
before passing the packet to the receive path? If you can
get to a point where all connections or traffic TO the router
should be AH, then, that will help with DOS.
There is no push from the operators to look at AH check or the
If DOS is such a large concern, IPSEC to an extent can be
used to mitigate against it. And IKEv1/v2 with IPSEC is not
the horribly inefficient mechanism it is made out to be. In
practice, it is quite easy to use.
IPSEC does nothing to protect a network device from a DOS attack. You
(Back in the days of dial-up, I had a lot of trouble
connecting to Bell Labs on snow days. No rule, and the place
was officially open for business. But everyone just did the
rational thing.)
I think the point is to start capacity and contingency planning now. Is
your VPN
Maybe now the US Gov can open their pocket book and pay for Skitter? :-)
-Original Message-
From: Martin Hannigan [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 05, 2006 10:55 PM
To: Etaoin Shrdlu
Cc: Barry Greene (bgreene)
Subject: Re: Did anyone else notice the CAIDA skitter
Here are some other new things (Cisco IOS specific):
Login Security Enhancements. The Cisco IOS Login Enhancements feature
allows users to better secure their Cisco IOS devices when creating a
virtual connection, such as Telnet, secure shell (SSH), or HTTP. Thus,
users can help slow down
my understanding is that md5 is still checked before the
ttl-hack check takes place on cisco (and perhaps most router
platforms). new attack vector for less security than you had
before. oh well. ras:
can you confirm that it is possible to implement ttl-hack and
have it check
For more information, see the talk by Dave Katz at
http://www.nanog.org/mtg-0006/katz.html
Also, AOL's experience in switching from OSPF to ISIS is
covered at http://www.nanog.org/mtg-0310/gill.html
the PDF on that page is actually an older version. The full
version I used at NANOG
I do not think there is a best practice. In fact, Operational
Entropy(1) has a big factor with packet filtering ACLs on the
interconnect side of an SP. So you are not going to find a lot of packet
filtering on SP-SP links.
There are links and presentations you can refer to help build a iACL
24 matches
Mail list logo
