Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle.

From: Stephen Kent <[email-masked]>
Date: Fri, 26 Jul 2002 15:41:05 -0400

Michel,

This is a WG to develop security requirements. The IESG has made it 
clear that security is a manor consideration for all protocol 
standards being developed. To that end, security needs to receive 
greater attention in the protocols you design, or they likely will 
not become IETF standards, if that is of any interest to you.

>WRT Steve's posting below, let me say very clearly that stating things
>such as "if you have a problem with man-in-the-middle things, just use
>IPSEC" or "let's not waste time documenting vulnerabilities issued from
>unprotected transport mechanisms" are of no use to me. I don't know
>IPSec, but I know enough about it to understand that the consequences on
>the global balance of the routing protocol I am trying to design are so
>bad that I can't use it.

Your second comment is intriguing. Do you plan on  elaborating how 
you have come to dismiss IPsec, despite an avowed ignorance of the 
protocol?

>In other words: my protocol (like many others) has a man-in-the-middle
>vulnerability, and the reason I don't use IPSEC to solve it is because I
>can't.

To paraphrase your comment above, that statement tells me nothing.

>
>>  Stephen Kent wrote:
>>  Over time I think the IETF has evolved to adopt a threat
>>  model that assumes man-in-the-middle attacks. We have some
>>  protocols that were designed with a more limited threat
>>  model, one that did not admit such attacks, and this has
>>  proven to be a mistake.
>
>Allow me to say mostly the same thing, viewed from another angle. When
>designing a routing protocol today, I have the general understanding of
>the security issue that is the current state of it. In other words, I am
>going to include in my protocol security mechanisms to dodge as many
>attacks as possible.
>
>Nevertheless, the bottom line still is: I'm doing my best, but it might
>not be enough.

Any maybe it's not good enough to become an IETF standard.

>  > If we assume that man-in-the-middle attacks are a
>>  valid concern,
>
>I think we should.
>
>>  then the details of the underlying transport protocol
>>  probably do not matter much, since we will require a
>>  crypto-security mechanism to protect the traffic.
>>  It also is appropriate to document the ways in which a
>>  routing protocol relies on the underlying transport
>>  protocol. I don't think that documenting vulnerabilities
>>  of otherwise unprotected transport protocols is the best
>>  strategy for our work.
>
>My problem is that the crypto-security mechanism that I could use to
>protect the traffic does not exist. Until it is invented, I think that
>it is appropriate to document the vulnerability, as correct operational
>practices could reduce its scope; I do think that operational practices
>recommendations or BCPs are definitely within the scope of this WG.

So, to summarize, you admit to knowing nothing about crypto and 
little or nothing about the IETF standard protocol for IP layer 
security, but you are confident that nothing exists that can address 
MITM problems for your routing protocol.  Is that about it?

Steve

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

---

From: [email-masked]
Date: Fri, 26 Jul 2002 17:17:34 -0400 (EDT)

>In other words, I am

The sticky problem comes when there exist several attacks:
Attack 1 can make the Internet routing fall over in a heap
Attack 2 can make the Internet routing fall over in a heap
Attack 3 can make the Internet routing fall over in a heap

Now, if Attack 1 and 2 can be countered quite easily without adversely
affecting your protocol, but Attack 3 takes a lot of work, then what?
Countering Attacks 1 and 2 would definitely be a good thing, but you're
left with the uncomfortable result that the Internet is still subject
to falling over in a heap.

The classic answer to problems like this are (a) buy bigger hardware
(hey, the windowing systems on our workstations are definitely a drain
on the workstation's ability to devote cycles to sheer computation - it's
just that nobody cares) and (b) use some sort of operational controls
to counter the attacks.  Like licensing to avoid the clueless,
inspections to spot the careless, incarcerations to punish the malicious,
etc.

WRT your comments about IPSEC msg round trips - in some cases, that should not
be a problem because the IPSEC connection establishment does not happen
that often - BGP peering sessions or OSPF adjacencies get established
and should not change that often.  Perhaps your protocol is different.
Lord knows the ad-hoc protocols have a problem in frequent topology
changes, maybe yours is also quite dynamic.  In that case, maybe a
group protection would be suitable (there are groups working on that
as well).

Not all solutions work with all protocols, but they all have a common
goal: to preserve the data source authenticity of the messages a
router receives.  We can state that goal as a security requirement.
Maybe we can also give examples of solutions that will meet that
requirement (tho' I think the charter says we're not looking at
mechanisms at the moment), maybe related to a characterizaton of how
the protocol works.  But we can't possibly list all possible solutions
to all possible existing protocols much less to all possible future
protocol designs.

--Sandy

---

From: "Michel Py" <[email-masked]>
Date: Fri, 26 Jul 2002 17:55:03 -0700

> Stephen Kent
> So, to summarize, you admit to knowing nothing about crypto
> and little or nothing about the IETF standard protocol for IP
> layer security, but you are confident that nothing exists that
> can address MITM problems for your routing protocol. Is that
> about it?

I'm not confident that it does not exist, I just haven't found. Can you
point me to something?

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 26 Jul 2002 18:29:26 -0700

Gregory,

> Gregory Lebovitz wrote:
> [Gregory] can you explain why you don't want privacy (data
> encryption) of the control plane messages, i.e. the routing
> protocol messages themselves? If we assume either a man-in-
> he-middle or an eaves-dropper threat, then one of the
> protections we would want is concealing the contents of
> the rp itself, no?

The routing protocol messages themselves contain nothing confidential.
The attacker would be able to obtain them easily by sending regular
requests from his own endpoint; no need to encrypt that part.

The threat that has been identified is that the attacker could feed an
endpoint with forged routing protocol messages, that would fool the
endpoint and make it send the traffic to a blackhole, or to the
attacker.

I other words, I just need to make sure that a routing update _really_
comes from the router it says it does.

> [Gregory] The back-and-forth packets are not actually from the
> IPsec, but from the IKE, the negotiation of the IPsec SA/keyes.
> Today, that negotiation is 6 packets, three in each direction.
> And yes, we have seen that in the wild it can take up to 4
> seconds using Pre-Shared Secrets, and quite a bit longer, up
> to 10 seconds or more, if using Certificates are used (especially
> long when a Revocation List must be retrieved to check peer's
> certificate status is not revoked) to complete the full
> IKE/IPsec negotiation.

Anything longer than 200 ms is a show stopper for me (and I expect
screams asking for a lot less).

> [Gregory] IPsec itself actually requires no in-band negotiation.
> The sa and keys can be manually entered on both sides. But we have
> found this completely unscalable and difficult to manage. In
> addition, it ultimately leads to poorer security, because operators
> set the SA parameters and keys once and then forget about them;
> key freshness becomes an issue.

The scalability requirement I have is any prefix to any prefix, out of
2.5 Billion possible ones. No manual configuration is possible here. It
might be interesting for you to have a quick look at the tentative
addressing plan, as we are talking about the protocol to support it.
http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt

> [Gregory] I don't believe this info is o/t. I provide this info
> for others (sounds like you already know it) for this reason: if
> RPsec is going to sooner or later require some crypto mechanism
> for auth/privacy/data integrity/non-repudiation/anti-replay,

Likely, IMHO.

> then we are going to need to consider the key negotiation overhead
> of the system, and how that will affect adjacency establishment,
> timeouts, etc.

I completely agree. Allow me to re-phrase: The reason I am not using
IPSEC is not because of IPSEC itself but because I do not know about any
key/certificate distribution mechanism that IPSEC could use and that
could suit my needs.

The point I was trying to make is this: I have heard too many times
"MITM is a no-brainer, use IPSEC and your MITM issue is solved".
It just is not that simple.

>> Also, there have been extensive concerns on the ipv6mh mailing
>> list about "crypto DoS", which is that it is easier to DoS a
>> router that uses crypto by feeding it encrypted packets full of
>> foo (the rationale being that most routers can't handle decrypting
>> packets at line speed), vs. a brute-force bandwidth based DoS.

> mdfranz wrote:
> While this might be possible depending on the AH/ESP implementation,
> the real DoS problem with IPSEC is with IKE. Because it relies on UDP,
> many implementations are vulnerable to complete CPU exhaustion (even
> remote blind) usng only a small number of Message 1's (a fraction for
> non-crypto based DoS's) because they start doing the RSA stuff
> immediately. This is even the case with hardware accelaration.
> However, I believe there are various proposals in the works (such as
> JFK) to fix the DoS problem.

I another post replying to Sandy, I will address this issue.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 26 Jul 2002 18:34:29 -0700

Sandy,

>> Michel Py wrote:
>> In other words, I am going to include in my protocol security
>> mechanisms to dodge as many attacks as possible.

> Sandy wrote: 
> Now, if Attack 1 and 2 can be countered quite easily without
> adversely affecting your protocol, but Attack 3 takes a lot of
> work, then what? Countering Attacks 1 and 2 would definitely be
> a good thing, but you're left with the uncomfortable result that
> the Internet is still subject to falling over in a heap.

Correct.
However there is some threat assessment to be done, as well as some
pros/cons analysis.

Threat assessment:
In my case, attack 3 requires sniffing the traffic inside the telco.

Two solutions:
1 - Do nothing, live with the attack 3 vulnerability.
2 - Use IPSEC / IKE
    Pros: - solves the MITM vulnerability.
    Cons: - creates a new vulnerability: crypto-DoS.
          - complexity / cost.

Let's forget about the complexity / cost issue for the moment. What do
you prefer?
- a) A man in the middle attack that requires telco class sniffing.
- b) A DoS that can potentially be launched by a script kiddie.

> WRT your comments about IPSEC msg round trips - in some cases,
> that should not be a problem because the IPSEC connection
> establishment does not happen that often - BGP peering sessions
> or OSPF adjacencies get established and should not change that
> often. Perhaps your protocol is different.

It is. A large part relies on BGP, and the scope of the problem we are
discussing is _not_ securing the BGP peering sessions, as a 5-second
delay to establish them once in a while is insignificant.

> Lord knows the ad-hoc protocols have a problem in frequent
> topology changes, maybe yours is also quite dynamic.

It's more than dynamic, it's on-demand, any-to-any.

> Not all solutions work with all protocols, but they all have
> a common goal: to preserve the data source authenticity of
> the messages a router receives.  We can state that goal as
> a security requirement.

Exactly what I need, but not at the cost of a 5-second latency.

> But we can't possibly list all possible solutions to all
> possible existing protocols much less to all possible future
> protocol designs.

Of course we can't. But that does not mean that we could rely on generic
mechanisms to solve generic problems either.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Fri, 26 Jul 2002 18:48:00 -0700

Michael,

Michel> It's a matter of extra latency. Long story made short,
Michel> the concerned part of MHAP is a three-way (client,
Michel> rendezvouspoint, endpoint), connectionless, UDP based
Michel> animal. Note that authentication / signing (vs. data
Michel> encryption) is what I am looking for, and it does
Michel> require some crypto magic.

> Michael Richardson wrote:
> Sorry, Michel, you are asking for faerie dust. Stop dreaming.

I'm not dreaming, just thinking loudly that there might be some gains by
leveraging the RVP infrastructure. As you know, I did not make this a
mailing list project, just trying to find people to look at the issue.

> As I have said several times on the ipv6mh list.
> The bits-on-the-wire problem is SOLVED. The key agreement problem is
> also solved. The problem is the trust model.

I agree with you and I have stated it publicly before.

> See HIP.

I'm looking at it, I have to corner Francis in Atlanta.

> But it likely is DOS'able, you just may have to pay for
> public key cryptography rather than symmetric cryptography. It
> still requires that the trust problem be solved.

Agree.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Sat, 27 Jul 2002 12:29:31 -0700

> Senthilkumar Ayyasamy wrote:
> So, Is *robustness of a network* a SHOULD requirement?

It's a MUST, but the definition of robustness can be discussed. To that
regard, the exact same applies to security.

It appears to me that it might not clear to everyone on this list what
the job of a protocol developer is: my job is to put a bunch of pieces
together to create a protocol. These pieces are other protocols, mostly
already existing.

I have a great deal of control in the way I assemble the pieces
together, but I don't have the time to re-design each piece I am given
to work with.

That is where the compromise and balance comes into play.

If you give me requirements such as:
Security:   100%
Optimality: 100%
...
Robustness: 100%
Stability:  100%
I will gladly refer you to someone that is in the business of doing
miracles. I'm not, I'm in the business of designing protocols, which is
more something like deciding between:

Security:   85%
Robustness: 80%
vs.
Security:   80%
Robustness: 85%

Michel.

---

From: "Senthilkumar Ayyasamy" <[email-masked]>
Date: Sat, 27 Jul 2002 17:15:42 -0500

>From: Charles Lynn <[email-masked]>
>To: "Senthilkumar Ayyasamy" <[email-masked]>
>CC: [email-masked]
>Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle.
>Date: Sat, 27 Jul 2002 13:27:48 -0400 (EDT)
>
>Senthil,
>
> > A quick question!!!
> > I am often confused with the terms *robustness* and *security*. The
> > possible causes for lack of robustness is more than just security
> > breaches. It also includes routing misconfigurations or many other
> > reasons ( e.g MOAS conflicts in BGP.)
>I think it should be.
> > As a side note, do you assume the routers to be functioning correct
> > when defining threats and requirements?
>
>The presence of one or more compromised routers should definitely be
>considered when defining threats and requirements, as should be the
>possibility of the router being "misconfigured".
>
> > IPSEC or any type of encryption based authentication helps to
> > prevent attackers from hijacking protocol communication.  But any of
> > the common security mechanisms works on a basic assumption that
> > every node in a network works functionally correct.
>
>I think that is too strong.
>
> > But imagine a situation when some of the routers are malfunctioning
> > or acting as a DDoS agent.  Does current security mechanisms
>
>I suspect that the mechanisms applicable to malfunctioning routers
>are not identical to those for prevention of acting as a DDoS agent.
>E.g., DDoS agent prevention may include data-plane mechanisms.
>
> > provide an answer in such scenarios?  perlman's byzantine robustness
> > provides a solution by means of consensus approach. But i dont know
> > how much the consensus based algorithms are practical.
>
>While practicality considerations will influence what we can implement,
>or maybe the MUST vs SHOULD in the recommendations that we produce,
>I do not think that we should let them be the basis for excluding our
>consideration of the treats.  If we identify the problems, someone or
>some vendor may be motivated to find better solutions than we currently
>have in our tool boxes.
>
> > But my point is: the threat models SHOULD consider cases of networks
> > with malicious routers.
>
>I agree, especially where "misconfigured" is part of "malicious".
>
>Charlie

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

---

From: [email-masked]
Date: Tue, 30 Jul 2002 12:59:09 -0400 (EDT)

One thing I'm unclear of is whether you are talking about authentication
of the routing protocol packets or authentication of the data traffic.

>The combination of the fact that auth checks are required AND that the
>router can't process them at line speed has created a situation that
>allows the attacker to take 50% of traffic off with 3 gbit of bandwidth,
>where it would have needed 10 gbit of bandwidth without auth checks.

First: wowzers!  Do router routinely have to handle gbit of routing
packets?  (Hence my wondering if you're talking about data traffic
or routing protocol traffic.)  I don't know the answer here.  A quick
check of the potaroo site says that the FIB can be 100K-ish and the
RIB 300K-ish.  But those are entries, not bytes.

Second:  if the attacker can overwhelm your router with 3gbit of
authenticated routing protocol traffic and it takes him/her/it 10gbit
of unauthenticated routing protocol traffic but with .5M of unauthenticated
routing protocol traffic he/she/it can make your router do goofy and
harmful things to routing everywhere in the Internet - do you win
by making the routing protocols unauthenticated?

>Making these choices require a clear answer on:
>- Is the cure better or worse than the vulnerability?

Depends on whether you are worried about your router being overwhelmed
or your Internet being overwhelmed.

--Sandy

---

From: "Michel Py" <[email-masked]>
Date: Tue, 30 Jul 2002 11:32:08 -0700

Sandy,

> Sandy wrote: 
> One thing I'm unclear of is whether you are talking about
> authentication of the routing protocol packets or
> authentication of the data traffic.

Authentication of the routing protocol packets.

>> The combination of the fact that auth checks are required
>> AND that the router can't process them at line speed has
>> created a situation that allows the attacker to take 50%
>> of traffic off with 3 gbit of bandwidth, where it would have
>> needed 10 gbit of bandwidth without auth checks.

> First: wowzers!  Do router routinely have to handle gbit
> of routing packets? (Hence my wondering if you're talking
> about data traffic or routing protocol traffic.)

I see your point. Back in the original context of this issue: we are
talking about a Billion or more prefixes here. I will address this size
matter replying to a post from Russ I just saw.

> Second:  if the attacker can overwhelm your router with 3gbit
> of authenticated routing protocol traffic and it takes
> him/her/it 10gbit of unauthenticated routing protocol traffic
> but with .5M of unauthenticated routing protocol traffic
> he/she/it can make your router do goofy and harmful things to
> routing everywhere in the Internet - do you win by making the
> routing protocols unauthenticated?

Sometimes you do, and sometimes you don't. It depends on who the
attacker is. If the attacker is a script kiddie with no more than some
IRC bots, you actually win by making the routing protocol
unauthenticated. Since the script kiddie can't sniff the cookie in the
protocol, he/she can't make your router do goofy things with small
bandwidth and must go for the full bandwidth attack.

And yes, if the attacker can sniff your traffic in the middle of telco
cloud, you are screwed without authentication.

It all comes to the assessment of the threat: the world-class hacker
that happens to have an OC-192 sniffer is more dangerous, but there are
not too many of them. The script kiddie is less dangerous, but there are
lots of them. Nothing's either completely black or completely white.

Michel.

---

From: [email-masked]
Date: Tue, 30 Jul 2002 15:21:31 -0400 (EDT)

>Since the script kiddie can't sniff the cookie in the

Hm.  So do we just need to make sure IPSEC has a cookie?  I know it has
replay protection, but I don't know if that is nonce or timestamp or
big sequence number.  (Charlie Lynn or someone else at BBN :-) probably
knows IPSEC down to its socks and can answer the question with alacrity.)
I know that ISAKMP/IKE at one point had cookies to prevent clogging attacks
you're talking about.

I don't think that BGP/OSPF/RIP, etc. in their MD5 protections have cookies,
much less full replay protection.

--Sandy

---

From: "Michel Py" <[email-masked]>
Date: Tue, 30 Jul 2002 19:03:35 -0700

> protocol, he/she can't make your router do goofy things
> with small bandwidth and must go for the full bandwidth
> attack.

> sandy wrote:
> Hm.  So do we just need to make sure IPSEC has a cookie?

I included an unencrypted 64-bit cookie in MHAP (it's a random number).
Although it was not the original purpose, we have discovered discussing
security that checking that unencrypted cookie _before_ performing auth
checks greatly reduced the risks of crypto-DoS, as the attacker has to
sniff the cookie prior to any attack involving the router performing
crypto checks.

Michel.