Subject: [RPSEC] an anti-flooding mechanism for consideration

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Apr 2003 14:43:12 -0500

Folks,

At the last RPSEC meeting, a major topic of interest was how to 
quickly determine if purported management (vs. subscriber) traffic 
directed to a router was from an authorized source. The traffic of 
interest includes BGP traffic sent between peers, SNMP traffic 
between a management station and a router, etc. The goal of the 
discussion was to find a simple mechanism that allows a router to 
make a quick determination, probably on a line card, if a packet 
represents legitimate management traffic, so as to be able to reject 
bogus traffic that might overwhelm the router's management processor.

Ideally, candidate mechanisms should be resistant to 
man-in-the-middle attacks, however there also was interest in 
mechanisms that would not provide protection in this worst cast 
context.

One approach to addressing this problem occurred to me after the 
meeting. It is based on the use of hash chains, the technique that 
underlies one-time password schemes like S/Key. For this environment 
the technique could be used as described below. I'll describe the 
management station to router case; the inter-router case, which is 
easier in most respects, is left as an exercise ...

- Each authorized source of management traffic,  identified by source 
address, generates a hash chain. The chain is generated by selecting 
a random number as a seed, then applying a one-way hash function to 
the seed, and then to the result of that application, iteratively. 
The number of iterations represents the length of the chain, which 
translates into the number of messages that can be sent before the 
chain must be re-established.

- Using an authentic, integrity-secure channel to the router, (e.g., 
an SSL connection, a protected SNMP transaction, or a local 
configuration port), the final value of the hash chain and its length 
is communicated to the router that is the target of the management 
traffic.(For the peer router case, one might accept a simpler, less 
secure initialization mechanism, under some circumstances.) This 
procedure initializes the hash chain "channel." The router also needs 
to be configured with a window that represents how much out of order 
management packets can arrive and still be accepted. More on this 
below.

- Once the channel has been established, the management station can 
send traffic to the router by tagging it with the current hash chain 
value and its ordinal position in the chain. If the chain is of 
length N, the first transmitted value is N-1, then N-2, etc. A 
management station must use a separate seed for each chain and 
maintain a separate counter for each device it manages. The station 
could recompute each hash chain as it progresses, but pre-computation 
and storage of selected, intermediate chain values would make 
generation of each tag faster and of constant duration.

- A management packet would carry the tag (consisting of the chain 
value and counter value that it represents), which could be checked 
by the target router very quickly. The router would maintain a small 
array of recently received tags, on a per-sender basis, for each 
authorized sender. The array is needed to allow for out of order 
arrival, while still rejecting duplicates. The size of the array is a 
local configuration parameter. The computation is quite fast, since 
only one or a few (a function of the window size) iterations of the 
hash function need to be performed, and since the hash function is 
applied only to the hash value in the tag, not to the whole packet.

- The tag is not bound to the packet, so it is not a substitute for a 
secure end-to-end integrity mechanism. However, the problem we are 
trying to solve is that of quickly rejecting bogus management 
packets. An MITM attacker can substitute a bogus packet for a 
legitimate one, but he can do so only at the rate at which legitimate 
packets are sent by an authorized sender. Thus, for purposes of fast 
rejection, the lack of binding to the packet does not seem to be a 
problem.

- If the checking is performed on line cards, then it may not be 
feasible to maintain synch among multiple cards re the receive 
windows, or the synch may be imperfect. (This assumes that the same 
authorized management traffic peer might legitimately send traffic 
that would arrive via any external interface. For the simpler case of 
a peer router sending IS-IS, OSPF, or BGP traffic, this is not an 
issue.)

- A residual vulnerability arises in that one might accept as valid a 
packet that was already accepted via another interface, serviced via 
a different line card. This is not ideal, but if we eventually synch 
across cards, the window of vulnerability can be limited, and in any 
case the replay vulnerability is proportional to the number of 
non-synched interfaces on a router and the size of the window allowed 
for each authorized management peer, and the number of such peers.

- One open question is where to put the tag. To maximize generality, 
one might use an IP option (or extension header in v6), since that 
would allow its use with any higher layer protocol. Is this viable 
from the perspective of network operators and router vendors, or do 
we need to find somewhere else to carry the tag?

Comments?

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Apr 2003 16:37:49 -0400

At 5:20 PM -0600 4/4/03, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:
>  > The mechanism I describe has the property you note, since the hash
>>  chains are per source/dest pair.
>
>Yes. I noticed them, only after senting the reply.... But, bradner's
>draft also seems to provide one way of doing.

I had forgotten about Scott's PBK I-D, but your message caused me to reread it.

It has almost nothing in common with what I discussed in my message.

PBKs are public key pairs dynamically created and bound to entities 
in dynamic challenge-response exchanges.  I saw no mechanism in the 
PBK draft that would qualify as fast-to-compute authentication 
mechanism, which was the purpose of the mechanism I described.

So, could you explain how you think the PBK notion relates to the 
problem discussed at the last RPSEC meeting, and to the features of 
the solution I offered in my message? The linkage is not at all clear 
to me.

Steve