See http://www.whitehouse.gov/pcipb/
A news story I saw said that they're treating this as a draft, too, and
asking for two months of public comment.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com ("Firewalls" book)
Wow, we should all start using out of band management. Anyone think it is
feasible to do management of an IP network exclusively out of band?
And BGP should be more secure. What is the problem we should be trying to
fix here? There is a "Secure BGP" draft:
http://www.ir.bbn.com/projects/sbgp/draft-clynn-s-bgp-protocol-00a.txt
Implementing this may make BGP very secure, but it will make the internet
as a whole much less reliable because routing will no longer be a function
that can be performed autonomously by routers, but something that's tied
into a global (public key) infrastructure. An infrastructure that depends
on routing to work... Hello circularity.
I read solutions (well, avenues for possible solutions) without a good
indication of what the problem is. (That goes for both the Secure
Cyberspace and S-BGP drafts.)
> See http://www.whitehouse.gov/pcipb/
Wow, we should all start using out of band management. Anyone think it is
feasible to do management of an IP network exclusively out of band?And BGP should be more secure. What is the problem we should be trying to
fix here? There is a "Secure BGP" draft:
http://www.ir.bbn.com/projects/sbgp/draft-clynn-s-bgp-protocol-00a.txt
I think the problem that people are attempting to address is
the fact that most interprovider bgp sessions are unfiltered and
this can cause significant problems if someone starts leaking
improper routes or decides to do something malicious.
Authentication of routing announcements is seen as better than
"just letting it all slosh around".
Implementing this may make BGP very secure, but it will make the internet
as a whole much less reliable because routing will no longer be a function
that can be performed autonomously by routers, but something that's tied
into a global (public key) infrastructure. An infrastructure that depends
on routing to work... Hello circularity.
Well, you need to have graded levels of trust. You will trust
your upstream more than your customers obviously. But yeah, there
do become some issues if people aren't doing local mirroring of
the dataset and they break their configs badly and need to
reconfigure. This does increase the barrier to entry significantly
in getting your announcements out there.
I read solutions (well, avenues for possible solutions) without a good
indication of what the problem is. (That goes for both the Secure
Cyberspace and S-BGP drafts.)
Well, there are significant problems today with router
architecture that prevent s-bgp and other things from being deployed.
Namely start looking at those still using 2500/4500/4700 for bgp in
their networks (yes people still do this) and then ask it to do some
major cryptograhic authentication... The hardware is not designed
for this. Even a reasonable amount of todays 'modern' hardware may not
be able to handle this due to the centralized architecture. (take the
above router types as example as well as any others that don't have
distributed forwarding).
When "W" goes surfing the net at night to shop for things
on ebay and can't get there because someone is improperly announcing
a /24 to hijack/DoS them, these are the things that they will suggest
down that there needs to be authentication and centralized routing
data created. Take a look at the LERG sometime if you have the
ability to see it. Lists the CLLI for each NPA-NXX that you are required
to deliver the call to. There are those that understand that
there are more complicated lookups involved but without people
from the industry providing feedback and playing hawk on the gov't,
we may not like what they come up with if we don't get people involved.
- jared
> And BGP should be more secure. What is the problem we should be trying to
> fix here? There is a "Secure BGP" draft:
> http://www.ir.bbn.com/projects/sbgp/draft-clynn-s-bgp-protocol-00a.txt
I think the problem that people are attempting to address is
the fact that most interprovider bgp sessions are unfiltered and
this can cause significant problems if someone starts leaking
improper routes or decides to do something malicious.
Authentication of routing announcements is seen as better than
"just letting it all slosh around".
It does. But the problem is that what you can know to be good is very
likely to be a lot less than what is actually good. So if you simply start
requiring authentication, you're going to break reachability in some
places.
> I read solutions (well, avenues for possible solutions) without a good
> indication of what the problem is. (That goes for both the Secure
> Cyberspace and S-BGP drafts.)
Well, there are significant problems today with router
architecture that prevent s-bgp and other things from being deployed.
Namely start looking at those still using 2500/4500/4700 for bgp in
their networks (yes people still do this) and then ask it to do some
major cryptograhic authentication... The hardware is not designed
for this.
The protocols aren't designed for it either. This is a good thing, because
every router can run the necessary protocols autonomously. But it also
means a huge duplication of effort. It seems pretty ridiculous to me to
have each and every router do strong crypto on each and every BGP update.
This kind of stuff should run on centralized servers with adequate disk
capacity to cache results.
The hard part is integrating such a solution into what we have now. I'm
thinking of a protocol that enables BGP routers to consult "policy
servers" about the updates they receive. When very strict security is
required, the router waits for the PS to clear the update before allowing
it, but in a less strict setup the router could process updates and remove
the routes later if the PS doesn't like them. In this case, loss of the PS
doesn't break the network. So we still have autonomy and implementing new
security features becomes much easier because only the policy servers have
to know about them.
When "W" goes surfing the net at night to shop for things
on ebay and can't get there because someone is improperly announcing
a /24 to hijack/DoS them,
Announcing a /24 you have no business announcing is a VERY hard thing to
do. The overwheling majority of all ISPs has strict filtering on BGP
announcements from customers. Now if the same were true for source address
filtering for IP packets, it would be possible to adequately filter DoS
traffic (unless massively distributed in nature).
these are the things that they will suggest
down that there needs to be authentication and centralized routing
data created.
Actually this particular BGP weakness isn't that hard to address: you only
need to verify the first few AS numbers in the path and the prefix using a
routing registry. You don't even need any crypto (in BGP, at least) for
that. And if you want to make it really secure you can add a signature
attribute at the source. That costs extra memory in routers, but it's
doable.
My problems are with the assumption in the S-BGP draft that information in
BGP must be protected against modification by routers it passes
legitimately. I think some reasonable level of trust is necessary. After
all, we trust others to prepare our food, stop for a red light when we
cross the road and so on.
Or maybe we can all promise to password protect our BGP sessions?
Welcome to my nightmare.
Getting ISPs to participate is always difficult. I encourage ISPs to read
the draft and send in their comments to the White House. Otherwise,
because they are the ones particpating, the future Internet security
architecture will probably look like what a big telco thinks is a good
security model. Why separate the circuit into 2B+D, just give me all the
bandwidth.
Is the telephone security model better than the Internet security model?
It depends on who you ask. They both have interesting security issues.
Unfortunately, a lot of it is based on perception on both sides, and only
a little on fact.
I would love to see some proposals from different ISPs how they view
the Internet (or ISP) security architecture. Cisco, Sun, Lucent and
Telcordia have vendor architectures. But what architecture work for
real ISPs? What can we point to as a "good" Internet security
architecture? Is there a difference between what works for a small,
medium or large ISP?
I can draw Internet security architectures until my fingers fall off, but
they won't have the impact of industry consensus.
:Is the telephone security model better than the Internet security model?
:It depends on who you ask. They both have interesting security issues.
:Unfortunately, a lot of it is based on perception on both sides, and only
:a little on fact.
Indeed, I am currently trying to retrofit security features onto a routed
network designed by people who evidently have a better understanding of
switching. It is no coincidence that they just happen to be telco network
architects. (I can't believe I am still describing the importance of
DNS to people in 2002, but I digress..)
IMHO, the telco model is based on the notion of delivering services
from a set of tiered providers instead of the facilitating the
interconnection of relatively autonomous networks. It's pretty
much a difference of philisophical worldviews. While there is
some conceptual overlap between them, they are not particularly
isometric.
From a security perspective, the recommendations in this report are
the same things that have been advocated for the last decade. In fact
it looks like many of these recommendations could have been culled from the
various vulnerability assessment report templates I have seen and even
used over the years. I don't mean to undermine the importance of the
strategy, but I think its impact will be through adding weight to us
Cassandras in the security industry.
Maybe they'll legislate Cisco's SAFE architecture on us all? 
:I can draw Internet security architectures until my fingers fall off, but
:they won't have the impact of industry consensus.
Well, I think the consensus was just handed to you in the form of a national
mandate. In fact, I think this looks like an excellent premise for
a business plan for a security consulting and managed services firm.
Got Capital?
Cheers,
Can you say "Counterpane Systems"? I knew you could.
Thing is, if this does turn out to be a big win for them, I figure they'll actually do what is right and not what the government says.
Maybe that's why they probably won't be the real "winners" out of this.
Anyone want to make any guesses as to who's going to be the Microsoft of US Government-mandated computer security? Hmmm.... Maybe Microsoft? Why not? They bought the government to begin with and the top computer security guy in the administration used to work for them, so it only makes sense that they would reap the windfall.
People expecting the government to wave a magic wand and make us all safe
will be disappointed. Security consulting firms probably aren't going to
get a windfall from the publication of the national strategy. But if you
had more modest goals, the strategy did accomplish some things.
Despite the daily drumbeat of vulnerability announcements, there really
aren't any new fundamental causes of security problems. The National
Academies of Sciences published a report last year recapping 10 years of
computer and network security studies. http://www.nap.edu/catalog/10274.html
The particular instance may change, but the classes of security problems
are unchanging.
Although the security problems are the same, the solutions can change. In
the 1980's I had a Multics/Dockmaster account. Multics may have been
secure, but the system sucked. Perimeter firewalls may not be the
security solution for the next decade. Would anti-virus software
become obsolete with a better kernel? Are the same password rules
we had for our one mainframe account applicable in today's web with
dozens of "logons"?
I think we need to re-evaluate our best solutions for our security
problems.
That National Cybersecurity Strategy did a nice job of collecting the
problems from all groups into one document, and showing an interdependence
between the groups. Simply securing one industry, company or home user
isn't enough to solve the problem. I especially pleased that at least
part of the US government now seems to recognize that security is more
than just secrecy.
Could the government move faster?
It took over 15 years from the introduction of seat belts on an American
car until they became "standard" items in American cars. The government
only "mandated" seat belts after most car makers were already offering
them. There were a lot of studies along the way. A democratic government
can't get too far out in front of the public.
American Seat Belt History (http://www.lemurzone.com/airbag/belts.htm)
1947 The first time seat belts were offered in a American car was the
Tucker. The state of the art then were Lap belts.
1956 Ford introduces seat belts in American cars
1964 Seatbelts became a "standard" feature in American cars
1966 Rear Seatbelts became Standard
1967 Front Seatbelts became Mandatory
1968 Shoulder Belts became Mandatory
Nevertheless, seat belts won't help unless the driver buckles up.
What exactly to do mean by "security architecture"?
Many network security efforts seem to be inspired by Descartes. Several
centuries ago, this very smart man sat down in front of the fire several
nights in a row and started doubting everything he could possibly doubt.
Senses, memory, everything. After all, everything that seems real may in
fact be an illusion created by a "malicious demon". (No, he wasn't talking
about a worm or trojan.) I'm not sure what his conclusion which can be
simplified as "I think, therefore I am", would translate to. Maybe "I
encrypt, therefore I am secure"?
Anyway, in our efforts to see security weaknesses everywhere, we might be
going too far. For instance, nearly all our current protocols are
completely vulnerable to a man-in-the-middle attack. If someone digs up a
fiber, intercepts packets and changes the content before letting them
continue to their destination, maybe the layer 1 guys will notice, but not
any of us IP people.
So what should we do? It seems each and every protocol is now trying to
solve the exact same problem. A better solution would be to adopt IPSec
throughout the net. But that doesn't protect you from a denial of service
attack: the man in the middle can just discard your packets. Even worse,
if you have to do crypto for every packet you receive, an attacker can
simply send packets that only turn out invalid after performing expensive
cryptographic operations and have you burn CPU cycles like it's going out
of style.
What we need are realistic expectations. Yes, the internet is vulnerable
to some degree, but the risks are nothing to worry about relative to
eating food that strangers have prepared or driving at high speed between
many bad-tempered people who are all armed with a ton of steel. For
regular day-to-day stuff such as off-topic rants and downloading
copyrighted material, the vulnerabilities that exist aren't really an
issue: the expense and effort to break into a _network_ (rather than just
some box connected to it) is not worth the gain. And for things that are
more sensitive: refer to the end-to-end principle. SSL isn't perfect, but
it's widely available. IPSec is more perfect, but less available. They'll
both run fine over the current network.
However, that doesn't mean we can lean back do nothing. Some protocols are
really too insecure. Please be assured that these problems have the
attention of the IETF. Everyone should feel free to donate time to help
develop newer, more secure protocols or newer, more secure versions of old
ones.
In the mean time, many people are still doing things they shouldn't, and
not doing things they should. If properly implemented, it is very hard to
break BGP. But that means everyone has to use antispoofing packet filters,
have strict filtering on the routes they accept from their customers and
preferably on those they accept from their peers as well, and use TCP MD5
password protection on all BGP sessions. That's something we can all do
before the month is out and it will actually make the net more secure
without breaking anything.
Iljitsch van Beijnum
I'm waiting for one of the professional security consulting firms to issue
their weekly press release screaming "Network Operator Meeting Fails
Security Test."
The wireless networks at NANOG meetings never follow what the security
professionals say are mandatory, essential security practices. The NANOG
wireless network doesn't use any authentication, enables broadcast SSID,
has a trivial to guess SSID, doesn't use WEP, doesn't have any perimeter
firewalls, etc, etc, etc. At the last NANOG meeting IIRC over 400
stations were active on the network.
Are network operators really that clueless about security, or perhaps we
need to step back and re-think. What are we really trying to protect?
Banks are mostly concerned about people defrauding the bank, not the
bank's customers. Banks rarely check the signature on a check. Is
security just perception?
I'm waiting for one of the professional security consulting firms
to issue their weekly press release screaming "Network Operator
Meeting Fails Security Test."The wireless networks at NANOG meetings never follow what the
security professionals say are mandatory, essential security
practices. The NANOG wireless network doesn't use any
authentication, enables broadcast SSID, has a trivial to guess
SSID, doesn't use WEP, doesn't have any perimeter firewalls, etc,
etc, etc. At the last NANOG meeting IIRC over 400 stations were
active on the network.Are network operators really that clueless about security, or
perhaps we need to step back and re-think. What are we really
trying to protect?
the nanog net is not run by network operators. it is run by some
well-meaning non-op folk from merit. for example, if i can gather
the patience (unlikely), next week i will join the third conference
phone call to try to explain to the merit folk why it's really ok
to put vern's bro ids on the incoming. and the merit powers that
be specifically forbid warning folk about the wireless, showing
caught passwords, ... as we do at ietf.
the nanog net is run *for* operators, not *by* operators.
btw, the ietf/atlanta net will be run by operators. if you would
care to discuss how to make the wireless safer, we're all for it.
but do not be fooled that it is an easy problem. e.g., wep is a
joke, and is very hard to get people to set up.
randy
I'm waiting for one of the professional security consulting firms to issue
their weekly press release screaming "Network Operator Meeting Fails
Security Test."The wireless networks at NANOG meetings never follow what the security
professionals say are mandatory, essential security practices. The NANOG
wireless network doesn't use any authentication, enables broadcast SSID,
has a trivial to guess SSID, doesn't use WEP, doesn't have any perimeter
firewalls, etc, etc, etc. At the last NANOG meeting IIRC over 400
stations were active on the network.
What do you mean "trivial to guess", its started at www.nanog.org. 
I'm not aware of any wireless networks setup at conventions with the
purpose of sharing confidential data and keeping people out. It is there
as a "public service", for everyone to use. I'm certain that the company
providing the bandwidth doen't put it inside their corporate firewalls.
Would WEP solve anything other than keeping the casual person on the
street who doesn't know what NANOG is from getting free bandwidth for a
couple days? I don't think so.
Are network operators really that clueless about security, or perhaps we
need to step back and re-think. What are we really trying to protect?
If I sit down at a crowded presentation with a Windows laptop, I'm sure to
get an infrared connection to at least 3 people within 10 minutes. If I
set my wireless to ad-hoc mode, I can find at least 10 people in any given
room with open shares. And if you ever fire up a sniffer, you'll get a
good laugh. Hundreds of plaintext passwords, plaintext mails, people
irc'ing, hell there are even warez transfers. There are also people
ssh'ing to personal and corporate machines from the terminal room where
the root password is given out or easily available.
Clearly *SOME* NANOG participants aren't terribly security conscious. But
are these the experienced network operators, or just the people who show
up because someone at their company thinks its a network training camp?
That's what the password board is for I guess.
bank's customers. Banks rarely check the signature on a check. Is
security just perception?
Yes.
And I would expect that those people who cared about things
assumed the wireless network was insecure (just like internet)
and had secured their hardware and were using secure connection
protocols: ie: SSH.. SSL.. (oh.. do they have holes?)
Still, we do what we can.
Terminal Rooms are no different then an internet cafe, you are using an
untrusted system to access an untrusted network, and should be treated as
such.
The wireless network, is just an untrusted network, send over it what you
would send over such a network. There is honor among thieves, but none among
idle network admins who left their nerf guns back at the office. ssh, or
encrypted vpn traffic is the only thing that should be sent over the network
to connect to remote systems.
Enabling WEP or setting a difficult to guess SSID would be silly, given that
it is a public network, the SSID would probably posted in the terminal room
anyways. Plus there are numerous tools to decrypt WEP in almost real time,
with 400 stations, it wouldn't take long to gather the needed packets.
Ultimately security is the responsibility of the person or organization
affected by the lack of it. Which is something most people fail to realize
consistantly.
Sameer
...
Are network operators really that clueless about security, or perhaps we
need to step back and re-think. What are we really trying to protect?
This is often something that gets forgotten.. people are so hyped up about
network security they can easily end up with ultra secure systems that really
arent worth it for the data thats there..
Banks are mostly concerned about people defrauding the bank, not the
bank's customers. Banks rarely check the signature on a check. Is
security just perception?
This is a case of your only as good as the weakest link.. I point this sort of
abstract thing out too. My usual examples are the office computers which tend to
be laptops kept overnight in empty unlocked rooms with no password on them;
people spend so much time getting secure VPNs and secure email setup they forget
if someone really wanted the data they'd just walk right in and remove the
hardware.
Doesnt mean we shouldnt maintain a high level of security and be vigilent, but
it does mean we should make sure we cover all angles.
I like your cheque example, again I pick on credit cards.. the banks get so
paranoid on internet shopping and yet its very common for fraud to occur because
of who sees your card when you're out shopping at the local store...
Think big picture!
Steve
I like your cheque example, again I pick on credit cards.. the banks get so
paranoid on internet shopping and yet its very common for fraud to occur because
of who sees your card when you're out shopping at the local store...
Actually, you are not correct. The credit card companies are not doing jack
shit to halt any kind of fraud since it lets them raise the rates a lot
higher.
One of my friends owns a mail order company that sells cigars. Every time
they flag certain transaction (both electronic or convention) as 'fraud' and
report it back to the CC company together with the address where stolen
goods are supposed to be picked up at, CC company never reports it to police
and gets the idiots. Why? Because they only lose 3% or so on transactions
but get to tell congress that they are losing 9%. Nice 6% goes right into
their pocket.
Follow the money trail and you will get your answers. As a certain
individual said five years ago "When insurance companies start jacking up
premiums for those who ignore security issues, *then* we will get everyone
doing something".
Alex
Would WEP solve anything other than keeping the casual person on the
street who doesn't know what NANOG is from getting free bandwidth for a
couple days? I don't think so.
The trouble is that not using WEP looks like you're not bothering with the
low level of security that's available in wireless. The fact that WEP only
adds a 15 second - 15 minute delay to full access to the network both for
legitimate and not-so-legitimate users means it offers more annoyance than
security, but that doesn't alter the perception.
There are also people ssh'ing to personal and corporate machines from
the terminal room where the root password is given out or easily
available.
Are you saying people shouldn't SSH?
Clearly *SOME* NANOG participants aren't terribly security conscious. But
are these the experienced network operators, or just the people who show
up because someone at their company thinks its a network training camp?
The real question is: how far we want to go in protecting people against
themselves? If the answer is: far, fine: then filter the wireless network
for everything that isn't SSH, SSL or some kind of VPN. Otherwise they'll
learn the hard way, just like why it's important to back up your files.
That's what the password board is for I guess.
Even more fun would be to scan for email headers and send messages back to
the originator that the message is being read over insecure means. That
should get some people's attention...
However, I think it's dangerous to talk about how insecure everything is
all the time. At some point, people are going to think it's no use to even
try securing their stuff and just give up. It would be better to deliver a
more positive message: if you use SSH, SSL and/or a VPN, you can do
whatever you want over a wireless connection without running bigger risks
than at home or at the office.
I've seen far too many people get into trouble because they have some
flawed thinking that "ssh == always secure", even against compromises of
one of the endpoints. If root is available, a reasonable person should
ASSUME that some bored individual (like Bandy Rush) has taken 30 seconds
and recompiled the ssh binaries with a password logger. Heck even if it
isn't available, you couldn't pay me enough money to trust public access
terminals to log into something which doesn't use a one-time password.
Excellent point. Fortunately, this doesn't apply to running SSH from your
laptop over the wireless network.
The trouble is that not using WEP looks like you're not bothering
with the low level of security that's available in wireless. The
fact that WEP only adds a 15 second - 15 minute delay to full
access to the network both for legitimate and not-so-legitimate
users means it offers more annoyance than security, but that
doesn't alter the perception.
but it adds annoyance for the intended users. in the case of non-
techs, considerable annoyance. and it gives negligible privacy.
There are also people ssh'ing to personal and corporate machines
from the terminal room where the root password is given out or
easily available.Are you saying people shouldn't SSH?
a prudent user does not ssh _from_ a machine they don't control or
strongly trust whover controls it. and a public machine should be
presumed to be dangerous. i don't ssh from the laptop of a friend
to whom i would not give root access to all of my machines.
the common attacks at nanog/ietf/... are
o intentional from the outside. one should be very prudent with
measures on servers etc, and install and monitor an ids such
as bro. this is bog standard net and system adminstration.
o intentional over the wireless.
- the users need to be told how to operate more safely, use
end-to-end authentication and privacy, etc. it's a matter of
education. and the education will stand them in good stead
when they use 802.11 at starbucks, airports, etc. we do this
at ietf, but it is not allowed at nanog.
- users need to be told when they're operating unwisely. we
post passwords or other embarrassing, but not revealing,
data. we will do this at the atlanta ietf, but it is not
allowed at nanog.
- and we need to monitor the air traffic to detect when users
are actually being exploited. this is an ops/research area,
but is being played with at ietf, but is not allowed at
nanog.
o unintentional dos of the wireless. this is caused by users'
mis-configurations of various kinds, win/mac configured as
access points, ad hoc mode, ... detecting and dousing these
are still an ops/research araa.
as far as i can determine, the reason standard education and
defenses are not allowed at nanog is because we fear the nanog net
operators monitoring traffic. i.e. we would rather have users
raped than have prudent folk notice them in their skivvies. hear
no evil, see no evil, speak no evil. it's a comfortable feeling.
randy