Re: [RPSEC] about the meeting at IETF 66

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
[e-mail] writes:
>  
> In the last month there have been discussions on the mailing list of
> the status of the milestone changes, and announcements of two new
> drafts, and a suggestion of looking at the
> draft-manral-rpsec-existing-crypto-02.txt draft.
>  
> That sounds to me like we have some topics for discussion at the rpsec
> meeting.
>  
> But no agenda was posted.
>  
> I hope the lack of an agenda does not mean that we won't meet.
>  
> Do the wg chairs have an agenda in mind?
>  
> --Sandy


Sandy,

When the topic of security has been discussed in IDR I and a few
others had been reminding the WG that common provider practices
provide a great deal of protection which makes up for weak
cryptographic protection of MD5 and no amount of cryptographic
protection prevents denail of service attacks which those provider
practices very effectively prevent.

Briefly, the practices are inbound filtering of BGP and OSPF and use
of GTSM.  IS-IS is not forwarded at all so not an issue.  By not
allowing OSPF and BGP from outside the network to be forwarded into
the network, a perimeter is established, where inside denial of
service and other attacks are not possible, so long as the perimeter
is not seriously compromised.  At the perimeter, BGP is spoken with
the immediate peer router and GTSM can be used.  An OSPF adjacency
could be established but in practice rarely if ever is.  GTSM provides
protection against attacks from more than one hop away.  If the
immediate peer router is compromised. then a denial of service attack
from the immediate peer is possible but for modern routers that denial
of service would only affect the peering with the compromised router,
which being compromised already is a more serious threat due to
ability to inject false routing information with the peering up.

Both protocol (OSPF) and port (BGP, TCP 179) packet filtering and
GTSM's TTL based filtering can be performed by routers at full line
rate making a denial of service attack against routing based on
traffic levels impossible.  This is not the case for cryptographic
protection alone.  ISPs have not been very concerned about the
weakness in MD5 since any form of cryptographic protection is regarded
as an additional redundant and only partially effective form of
protection.

The filtering capability and traffic attack hardenning on external
peerings can be cited as a requirement for routers.  In practice these
are far more important requirements than good crypto for an ISP
network.

A caveat of the filtering based protection alone is that any
compromise within the protected perimeter opens the possiblity of
attack from within the perimeter.  This is a house of cards problem.

If a core router today often with many tens of OC192c interfaces were
compromised, there are is very substantial potentials for denial of
service attacks, not just against routing.  There would also be the
ability to inject false routing information.

Any major provider today, being that they are attacked more or less
constantly, does not allow routing peerings outside the set of
infrastructure routers except route filtered peerings to customers at
the network perimeter, route filtered or unfiltered peering with major
peer providers, and one way peerings to their own NMS hosts or
subnets.  Of these the most credible threat is from NMS hosts, both on
external subnets, and embedded within the infrastructure (the pizza
box 1U server in the POP used by many providers, though often these
are just 100baseT interfaces).

Perhaps rpsec-existing-crypto is not the place for this information,
but it would be useful for RPSEC to document this as BCP.

I also recognize that there may be other applications of IP routing
where traffic volume is not as much of an issue (adhoc wireless for
example) and where either compromise of infrastructure hosts might be
possible (physical compromise, for example) or where the channels
cannot be assumed to be secure (wireless or other).  In those
situations, crypto security is needed and filtering is ineffective.
Any BCP on this topic should recognize both types of situation and
point out where each type of solution is applicable.

And of course if fiber carrying bundles of OC192c or other 10Gb/s or
higher encapsulations is compromised, there is no technology today
that can protect agains the resulting denial of service attack.  At
that point the link (or set of logical links) has to be shut down.

btw- If you really want to address lack of physical security better,
promoting strong encryption on non-volitile storage would be a good
idea.  It was well known that telco personnel were stealing the flash
cards from a certain type of router until the router was modified such
that some minimal disassembly was required and logging and NM traps
were added if the flash was removed.  Those flash were being sold as
PC hardware but also had complete router configurations on them.  If
you really wanted to be secure, the entire filesystem, not just access
passwords, would be encrypted such that the operator would have to
provide information if power were completely removed (not just across
a reload).  Physically removing hardware would do nothing initially
until the crypto was cracked which would at least take time, and as
long as the physical compromise was detected and acted on, keys
elsewhere could be changed before cracking completed.

Please let me know, on the WG list or offline, how and if this sort of
thing might fit into RPSEC.

Curtis

_______________________________________________
RPSEC mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rpsec