I hate when contact numbers are disconnected. Does anyone have a good
>> contact for MAI.net?
>
>no neighbor 192.41.177.73
^^^^^^^^^^^^^^^^^^^^^^^^^
they should not care if you peer with them or not, they can have
the upstream provider to give them your routes, then:
!
set nexthop 192.41.177.121
!
no neighbor 192.41.177.73
they should not care if you peer with them or not, they can have
the upstream provider to give them your routes, then:
!
set nexthop 192.41.177.121
Yes, folk seem to be doing this kind of thing, as shocking and disgusting as
it seems.
The problem is not agreements. The problem is, as Scott says, detecting
violation thereof is not easy. But traceroute -g is your friend.
E.g. UUNET's peering policy seems to be far more liberal than the press
would have us believe. [ undoubtedly some of these are valid UUNET peers. ]
I also think it may be time we refuse to peer with anyone who inhibits LSR,
as it seems that validation is now mandatory. I think we should be sending
out a "LSR is mandatory" notice to our peers. Comments?
Smaller peers. A non-trivial few are doing seriously disgusting things
which are going to cost you a lot of pain and some cash. There is little
incentive for larger folk to peer with smaller ones. Hence, larger peers
will simply cut the smaller masses off rather than spending the resource to
differentiate the bad apples from the good. Maybe you want to do something
about it. And soon.
randy
5 kirk.mae-east.verio.net (205.238.56.57) 168 ms 84 ms 107 ms
6 mae-east-01.ix.ai.net (192.41.177.98) 152 ms 136 ms 130 ms
7 * br2.tco1.alter.net (192.41.177.249) 150 ms 134 ms
5 kirk.mae-east.verio.net (205.238.56.57) 82 ms 84 ms 83 ms
6 mae-east.mai.net (192.41.177.73) 116 ms 111 ms 104 ms
7 br2.tco1.alter.net (192.41.177.249) 120 ms 127 ms 113 ms
5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 82 ms 83 ms
6 mae-east-fddi2.servint.net (192.41.177.66) 103 ms 87 ms 88 ms
7 * br2.tco1.alter.net (192.41.177.249) 310 ms 231 ms
5 kirk.mae-east.verio.net (205.238.56.57) 84 ms 82 ms 89 ms
6 mae-east.wdc.ixe.net (192.41.177.18) 100 ms 85 ms 94 ms
7 958.Hssi5-0.GW1.TCO1.ALTER.NET (157.130.32.109) 202 ms 219 ms 222 ms
5 kirk.mae-east.verio.net (205.238.56.57) 84 ms 82 ms 88 ms
6 mae-east.iconnet.net (192.41.177.75) 86 ms 88 ms 88 ms
7 br2.tco1.alter.net (192.41.177.249) 132 ms 123 ms 258 ms
rip:/home/randy/rain/config> traceroute -g 192.41.177.90 www.uu.net
traceroute to www.uu.net (199.170.0.30), 30 hops max, 40 byte packets
1 gw (147.28.0.58) 179 ms 4 ms 4 ms
2 fr0.sea.verio.net (205.238.52.65) 24 ms 11 ms 13 ms
3 sea1.sea.verio.net (205.238.56.101) 11 ms 12 ms 11 ms
4 sea.kirk.verio.net (205.238.56.69) 12 ms 12 ms 14 ms
5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 82 ms 84 ms
6 SR1.TCO1.ALTER.NET (137.39.127.1) 295 ms 273 ms 394 ms
7 Fddi0-0.CR2.TCO1.ALTER.NET (137.39.11.20) 334 ms 277 ms 123 ms
8 Fddi0-0.CR2.TCO1.ALTER.NET (137.39.11.20) 126 ms 189.Hssi1-0.GW2.FFX1.Alter.Net (137.39.70.69) 179 ms Fddi0-0.CR2.TCO1.ALTER.NET (137.39.11.20) 135 ms
9 charlotte01.va.pubnix.com (199.170.0.30) 185 ms 187 ms 401 ms
huh?
5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 88 ms 82 ms
6 mae-east.dx.net (192.41.177.92) 86 ms 91 ms 87 ms
7 904.Hssi3-0.GW1.DCA1.ALTER.NET (137.39.128.93) 104 ms 147 ms 108 ms
5 kirk.mae-east.verio.net (205.238.56.57) 82 ms 84 ms 85 ms
6 mae-east-01.ix.ai.net (192.41.177.98) 111 ms 118 ms 130 ms
7 br2.tco1.alter.net (192.41.177.249) 124 ms 122 ms 131 ms
5 kirk.mae-east.verio.net (205.238.56.57) 85 ms 84 ms 83 ms
6 fddi3-0.cr1.dca.globalcenter.net (192.41.177.113) 83 ms 84 ms 89 ms
7 Fddi9-0.BR2.TCO1.ALTER.NET (198.32.186.249) 433 ms * 138 ms
5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 107 ms 108 ms
6 mae-east.above.net (192.41.177.152) 99 ms 105 ms 92 ms
7 901.Hssi5-0.GW2.TCO1.ALTER.NET (157.130.33.113) 137 ms 117 ms 109 ms
rip:/home/randy/rain/config> traceroute -g 192.41.177.160 www.uu.net
traceroute to www.uu.net (199.170.0.30), 30 hops max, 40 byte packets
1 gw (147.28.0.58) 4 ms 4 ms 4 ms
2 fr0.sea.verio.net (205.238.52.65) 13 ms 11 ms 10 ms
3 sea1.sea.verio.net (205.238.56.101) 10 ms 10 ms 19 ms
4 sea.kirk.verio.net (205.238.56.69) 12 ms 13 ms 12 ms
5 kirk.mae-east.verio.net (205.238.56.57) 83 ms 85 ms 82 ms
6 br2.tco1.alter.net (192.41.177.249) 138 ms 136 ms 126 ms
7 332.atm10-0.cr2.tco1.alter.net (137.39.13.18) 118 ms br2.tco1.alter.net (192.41.177.249) 131 ms 332.atm10-0.cr2.tco1.alter.net (137.39.13.18) 131 ms
8 332.atm10-0.cr2.tco1.alter.net (137.39.13.18) 141 ms 114 ms 140 ms
9 189.Hssi1-0.GW2.FFX1.Alter.Net (137.39.70.69) 107 ms^C
At this point my lunch was ruined, and I gave up.
randy
} Subject: Re: not rewriting next-hop, pointing default, ...
% I also think it may be time we refuse to peer with anyone
% who inhibits LSR, as it seems that validation is now mandatory.
% I think we should be sending out a "LSR is mandatory" notice
% to our peers. Comments?
LSR is actually a significant security issue. So, while I do
understand and am sympathetic to the operational debugging
issues that LSR addresses, I think that requiring a peer to
enable LSR more than 2 hops inside their network from the
outside world is unreasonable.
In a world where SSH were available in cisco routers and/or
IPsec were more widely deployed, I might have different views.
However, we are where we are.
Regards,
Ran
rja@home.net
LSR is actually a significant security issue. So, while I do
understand and am sympathetic to the operational debugging
issues that LSR addresses, I think that requiring a peer to
enable LSR more than 2 hops inside their network from the
outside world is unreasonable.
So, you're comfortable with asking for LSR at the IX and a hop behind?
In a world where SSH were available in cisco routers and/or
IPsec were more widely deployed, I might have different views.
K5 does not give you sufficient warm fuzzies?
randy
I'd love to be able to reasonably run with LSR enabled.
However, we then become the "bounce point" for all kinds of fun stuff,
including denial of service attacks launched against *OTHERS*.
Its off at our entrance routers for this reason. If EVERY provider shut
it off EXCEPT on the core (ie: it was on where only network personnel could
get to and use it) I wouldn't mind. But with it on all the way to the end
customer circuit in many cases enabling it on your core can create some
serious security problems.
We *used* to run with it on, and shut it off for exactly this reason.
Get a few connections to your core hardware hijacked and you'll start
installing hardwired modems on console ports and shutting off access to
the telnet side entirely.
That's a SERIOUS pain in the arse.
} Subject: Re: not rewriting next-hop, pointing default, ...
LSR is actually a significant security issue. So, while I do
understand and am sympathetic to the operational debugging
issues that LSR addresses, I think that requiring a peer to
enable LSR more than 2 hops inside their network from the
outside world is unreasonable.
% So, you're comfortable with asking for LSR at the IX and a hop behind?
"Comfortable" isn't the word I'd choose. Ideally, I'd filter
out LSR entirely [1], but there are real operational issues.
Letting LSR in two hops lets outsiders trying to debug (e.g. some
routing problem) at least perform first-level fault-isolation
so they know whose NOC to call for further debugging assistance.
So I view the 2-hop notion as an attempt at "reasonable compromise".
In a world where SSH were available in cisco routers and/or
IPsec were more widely deployed, I might have different views.
% K5 does not give you sufficient warm fuzzies?
No, I'm afraid that Kerberos 5 doesn't give me sufficient warm
fuzzies. I don't care to be very detailed on a public list
such as NANOG. I will note that aside from my non-public
concerns, Kerberos-5 is expensive to deploy and maintain.
Kerberos can also adversely impact network availability if
it isn't installed in exactly the right way (surprisingly few
folks seem to do it right).
Ran
rja@home.net
[1] DISCLAIMERS:
- I'm not a security expert, so my opinion probably doesn't
mean very much in the grand scheme of things.
- I am NOT with @Home's Security Group, which is ably managed
by Mike StJohns, who is a Security Expert. So don't
blame them for my comments.
- I don't make policy for @Home, so my opinions are just mine
not my employer's.
- I haven't had enough coffee yet today. 
rja@corp.home.net (Ran Atkinson) writes:
Letting LSR in two hops lets outsiders trying to debug (e.g. some
routing problem) at least perform first-level fault-isolation
so they know whose NOC to call for further debugging assistance.
So I view the 2-hop notion as an attempt at "reasonable
compromise".
Cool, and I now view the 2-hop notion as the first
reasonable argument for encouraging people to totally
flatten their network into a full mesh.
Security policy should not under any circumstances prevent
the Internet as a whole from functioning reasonably well,
scaling decently, or make discovering and diagnosing
problems any harder than it already is.
Your opinion may vary with mine, but I am solidly in line
with Randy's suggestion that enabling LSRR on backbone
routers should be a requirement for peering. (This is not
surprising as I used to require it of a couple of peers in
a previous life, because in practice it is unfortunately
an irreplaceable diagnostic tool).
Sean.
% Cool, and I now view the 2-hop notion as the first
% reasonable argument for encouraging people to totally
% flatten their network into a full mesh.
Hmm. I wouldn't go that far :-).
% Security policy should not under any circumstances prevent
% the Internet as a whole from functioning reasonably well,
% scaling decently, or make discovering and diagnosing
% problems any harder than it already is.
A reasonable security policy is focused on maintaining
network availability and uptime. If one focuses exclusively
on diagnostic tools, one's network will be down much more
often than if one strikes a reasonably balanced overall
perspective on things. All IMHO.
% Your opinion may vary with mine, but I am solidly in line
% with Randy's suggestion that enabling LSRR on backbone
% routers should be a requirement for peering. (This is not
% surprising as I used to require it of a couple of peers in
% a previous life, because in practice it is unfortunately
% an irreplaceable diagnostic tool).
You haven't defined terms (e.g. "backbone router"), so your
meaning is not clear. Assuming that "backbone router" is
only those within 2 hops of an external connection and that
one has a network with nice deep heirarchy (much more than
2 levels), I could agree with you. 
I will note that its none of someone else's business what
one's internal topology looks like. The only _legitimate_
need of a peer is to be able to isolate the problem to
one's network (or someone else's network) so that the peer
can then come after one (or one's NOC) to fix the problem(s).
So I'm not trying to kill off LSR as a diagnostic tool, merely
limit the downside operational risks of LSR to a reasonable
level. The ultimate goal of my proposal is to _enhance_
network availability.
Ran
rja@home.net
Disclaimers from yesterday's note all apply; especially the
one about not enough coffee.
PS: I've revised the subject line to be more clear.
rja@corp.home.net (Ran Atkinson) writes:
A reasonable security policy is focused on maintaining
network availability and uptime.
How does a security policy of "turn off LSR handling" translate
into anything other than an admission of completely
missing the point that one should never ever ever ever
trust any data based soley on where the network leads one
to believe it has come from?
Turning off a useful but under-implemented network service
because it might be used to spoof the network origin of
management instructions or routing information misses the
point that the network origin is a really poor proof of
validity of the messages or authority to issue them.
Moreover, the under-implemented service itself may improve
the security of communications between end systems.
Quoting Radia Perlman:
"The goal is to design a network that will guarantee that
a packet transmitted between two nonfaulty end systems A
and B will have a high probability of being delivered,
provided that at least one path consists of nonfaulty
components connects the two end systems. [...] The
network layer makes no attempt to keep conversations
private. If privacy is necessary, encryption must be
done at a higher layer. Also, the network layer need not
certify data that it delivers. For instance, it is
possible for some malicious node C to generate data, get
it delivered to B, and claim that the data was from A.
It is up to the higher layer in B to differentiate
between corrupted or counterfeit data and real data,
using known cryptographic techniques".
The proposal to turn off LSRR is a tremendously incomplete
proposal to have the network certify the validity of the
origin, at the cost of some additional utility and
robustness from the point of view of end systems.
However, maybe this isn't so surprising as I've seen you
support another incredibly braindamaged security scheme
that trades off scalability of the Internet in general
for some degree of security between end systems.
The problem isn't one of ES-to-ES security but one of
endpoint to endpoint, where the ultimately the endpoints
are the data generators and receivers (human or
automation) who communicate through the end systems.
The lesson of Kerberos and SSH and so forth is that
ES-to-ES security is useless if one of the ESes itself is
compromised.
If one focuses exclusively on diagnostic tools, one's
network will be down much more often than if one strikes
a reasonably balanced overall perspective on things.
All IMHO.
But at least you will know WHY your network went down, and
might be have enough information to get it back up again,
and prevent the same thing from happening again. --
In any event I don't think that disabling LSRR in any way
makes networking equipment more robust, and that is what
you appear to be arguing.
I will note that its none of someone else's business what
one's internal topology looks like.
Sure it is. Or rather, it is useful to be able to infer a
number of path characteristics between two communicating
endpoints for such things as flow control and route
selection.
Networks and computers exist to offer services to users,
and obscuring information that makes service use or
selection difficult is a poor policy.
I would agree with you if you modified your note to,
"it is no business of anyone not authorized to use a
network what that network looks like beyond how it
presents itself externally", although this is incomplete
because it doesn't preclude marketers telling whopping
lies to potential authorized users. (caveat emptor? )
The only _legitimate_ need of a peer is to be able to
isolate the problem to one's network (or someone else's
network) so that the peer can then come after one (or
one's NOC) to fix the problem(s).
Again, networks exist to benefit users. The need of the
aggregate of networks called the Internet is to make users
happy, and usually involves more than "oh it's *their* problem".
Tools to provide meaningful diagnoses of ES-to-ES
connectivity that users can run on end systems is
work-reducing for network operators, particularly as those
network operators obviously would have access to the same
tools.
So I'm not trying to kill off LSR as a diagnostic tool, merely
limit the downside operational risks of LSR to a reasonable
level. The ultimate goal of my proposal is to _enhance_
network availability.
How does LSR reduce network availability except in the
case of implementations that slow-switch option-ridden IP
datagrams and have no equivalent of SPD, or intermediate
systems (gee, it's OSIspeek day, isn't it?) that don't
use reasonable means to authenticate and keep private
things like routing information exchanges or management sessions{
Sean.
> A reasonable security policy is focused on maintaining
> network availability and uptime.How does a security policy of "turn off LSR handling" translate
into anything other than an admission of completely
missing the point that one should never ever ever ever
trust any data based soley on where the network leads one
to believe it has come from?
It is called KISS principle. In computer security it is also called
minimizing possible risk.
Turning off a useful but under-implemented network service
because it might be used to spoof the network origin of
management instructions or routing information misses the
point that the network origin is a really poor proof of
validity of the messages or authority to issue them.
Correct. Fortunately, this does not mean that one should give up on it.
Quoting Radia Perlman:
"The goal is to design a network that will guarantee that
a packet transmitted between two nonfaulty end systems A
and B will have a high probability of being delivered,
provided that at least one path consists of nonfaulty
components connects the two end systems. [...] The
network layer makes no attempt to keep conversations
private. If privacy is necessary, encryption must be
done at a higher layer. Also, the network layer need not
certify data that it delivers. For instance, it is
possible for some malicious node C to generate data, get
it delivered to B, and claim that the data was from A.
It is up to the higher layer in B to differentiate
between corrupted or counterfeit data and real data,
using known cryptographic techniques".
Well, then he is *WRONG*. Authentication and privacy should be a function
of the network layer, not the application layer because it is a lot easier
to attack application layer encryption compared to lower layers.
However, maybe this isn't so surprising as I've seen you
support another incredibly braindamaged security scheme
that trades off scalability of the Internet in general
for some degree of security between end systems.
I think it is funny that network operators say "It must be done at the
application layer because otherwise my network won't scale" while
people that deal with applied crypto say "Are you nuts? Why do you want to
make every application utilize its own cryptographic method? You are
creating a weakness".
Face it, the security of any chain is equal to security of its weakest
link and currently that link is not host security.
The lesson of Kerberos and SSH and so forth is that
ES-to-ES security is useless if one of the ESes itself is
compromised.
Since when is that the case for Kerberos? Only if you compromise the KDC
you break security of the model. As ssh does not have any 3rd trusted
party that verifies credentials, it is definitely a case for ssh. Earlier
versions of it had some very interesting properties that could under
certain conditions have been used to impersonate a client and a server.
In any event I don't think that disabling LSRR in any way
makes networking equipment more robust, and that is what
you appear to be arguing.
While disabling LSR does not make network equipment more robust, it
prevents a series of very interesting attacks including DOS attacks
against that equipment.
> I will note that its none of someone else's business what
> one's internal topology looks like.Sure it is. Or rather, it is useful to be able to infer a
number of path characteristics between two communicating
endpoints for such things as flow control and route
selection.
So why don't we all have at least SNMP access to the routers of those
networks? A lot of people would surely want to what is going on inside
there?
I think the answer to this question is simple - such ability would
conflict with a security policy
Alex
"Alex \"Mr. Worf\" Yuriev" <alex@netaxs.com> writes:
It is called KISS principle. In computer security it is also called
minimizing possible risk.
Cool, as I just recently said, I love learning brand new
things from people older and wiser than me.
Well, then he is *WRONG*.
Dr Perlman's excellent book, _Interconnections_, ISBN
0-201-56332-0, Addison-Wesley, 1992, is probably the
definitive text on routing to that date, and subsequently
(d�sol�, Christian )
I would look forward to a new version which would take
recent developments in integrated IS-IS for IP (and in
IP), BGP with all its many new features, IDRP, and the
specification of NIMROD into account, since Dr Perlman is
not only very informative but also a fun read.
I think it is funny that network operators say "It must be done at the
application layer because otherwise my network won't scale" while
people that deal with applied crypto say "Are you nuts? Why do you want to
make every application utilize its own cryptographic method? You are
creating a weakness".
The latter group are lazy.
The former group has lazy people too, but it also has
people who use rather neat encryption on the physical
transmissions layers to prevent people with vampire taps,
microwave interceptors, or little satellite dishes
eavesdropping or forging traffic.
However, security at the physical layer, as with security
at the next two or so transport layers, is non-transitive.
You do not become more secure because you scramble the
bits inside your IP datagram than when you scramble the
bits in your TCP segment, and you make it harder to scale
using NATs and ALGs, which are the fundamental building
blocks of the growing Internet.
You also make it less possible to be fair using Van
Jacobson's excellent pleas to implement profile
enforcement towards the edges, or indeed, to implement
anything like RED/WRED/WFQ along parts of the path between
two endpoints scrambling everything inside IP datagrams.
Moreover, scrambling *all* communications or
authenticating *all* communications (thus preventing
things like Vixie's and Cisco's various
web-query-redirection software from working correctly) is
an insane waste of CPU time.
Consequently, encryption and authentication *is* something
you want explicitly turned on by applications, and if
possible it should generate sane (if not necessarily
transparently descriptive) TCP headers.
Implementation details are up to you host people types.
Throwing it back at network operators is silly. Our
market is in getting traffic around, not in solving
people's security problems (as if any solution proposed or
implmented by any ISP or set of ISPs would really
seriously be believed to be secure anyway).
Face it, the security of any chain is equal to security of its weakest
link and currently that link is not host security.
Yah, multiuser systems are really secure.
> The lesson of Kerberos and SSH and so forth is that
> ES-to-ES security is useless if one of the ESes itself is
> compromised.Since when is that the case for Kerberos? Only if you compromise the KDC
you break security of the model.
Ticket stealing is an old game. All you need is the right
file permissions and decent timing (it's usually a big window).
Ran Atkinson mentioned that K5 doesn't give him
particularly warm fuzzies. I'm sure you could ask him
some of his reasons, and get a lucid explanation of them.
He's bright, even if I don't find myself liking the IPSEC
model very much.
While disabling LSR does not make network equipment more robust, it
prevents a series of very interesting attacks including DOS attacks
against that equipment.
Which of those denials-of-service are not implementation
dependent, where the implementation generally is now fully
end-of-line Cisco 7000+RP or RSP-only equipment?
> Sure it is. Or rather, it is useful to be able to infer a
> number of path characteristics between two communicating
> endpoints for such things as flow control and route
> selection.So why don't we all have at least SNMP access to the routers of those
networks? A lot of people would surely want to what is going on inside
there?
Mostly because SNMP is a bad misdesign compared to earlier
efforts before SNMP's standardization, and the ability to
dig out what you really need to know is sometimes more
challenging using SNMP than observing TCP timings and
using hacks like provoking ttl exceededs.
I think the answer to this question is simple - such ability would
conflict with a security policy
I have trouble understanding why infering things about the
path, for instance, the amount of congestion, the round
trip times, the behaviour of queues, and so forth gets in
the way of security policies, but people who believe that
are, of course, more than welcome to use ALGs and
firewalling techniques to prevent access to their
networks.
Remember, the point is that only people authorized to use
your network should have access to the things you seem to
think are possibly heavy secrets. If you don't want
random people finding these things out, you don't let
random people use your network. It's quite simple.
However, if you do let random people use your network, you
probably should not cripple your own use of that
connectivity by doing stupid things in the name of some
slightly additional warm fuzzy security.
Sean.