Subject: [RPSEC] rate limiting management traffic, redux

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Apr 2003 16:40:45 -0400

Undeterred by the overwhelming response to my last posting on this 
topic, I've thought some more about it and have a simpler technique 
to propose.

Recall that the problem being addressed (which was the topic of two 
presentations at the last RPSEC WG meeting) is how to quickly 
determine if purported management (vs. subscriber) traffic directed 
to a router is 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 is to find a simple 
mechanism that allows a router to make a quick determination, 
probably on an interface 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.

My new suggestion in this area requires a shared secret (key) between 
the router and the entity sending the management traffic, either 
another router or a management workstation. The key is one of two 
inputs to a one-way function; the other input will be a sequence 
number which will be carried with the packet. The one-way function 
transforms the key and sequence number into an output that should be 
big enough to preclude effective guessing attacks. The one-way 
function is required to prevent a passive wiretapper from being able 
to work backwards from the output and the sequence number (which is 
visible in each packet) to determine the key. The key must be changed 
before the sequence number cycles, to prevent replay attacks.

The mechanism is quite simple. Each authorized sender of management 
traffic is identified by its IP address. Associated with each sender 
is a secret (key) that must be shared with the managed device, e.g., 
a router. The sender of the management traffic maintains a packet 
counter which is initialized to 0 and is incremented for each 
transmitted packet. Before transmitting the packet, the sender 
creates the authentication tag by applying a one-way function to the 
key and the sequence number. Both the sequence number and the tag are 
carried in the packet.

A managed device such as a router maintains a separate key for each 
entity that is authorized to send management traffic to the device. 
For each authorized sender, the managed device maintains the 
following information:
	- the address of the sender
	- the shared secret
	- a receive window consisting of the sequence number for the 
most recent, valid management packet from the sender, a sequence 
number indicating the edge for "too old" packets, plus a bit map 
marking received , valid packets within the window. This is the same 
mechanism used by IPsec to reject replays while allowing out of order 
arrival.

This data is maintained on each interface card via which management 
packets from the sender may be received. So, for example, if the 
sender is a neighbor router (for BGP traffic) only one interface will 
hold the data for that sender. If the sender is a management station 
from which traffic might be received multiple interfaces, then every 
appropriate interface would maintain this data for that sender. In 
this later case there is a synchronization issue, since the window 
would be updated locally on each interface where such packets are 
received. I think it would suffice to periodically update the window 
data in a loose fashion for these senders, since the vulnerability 
that arises from imperfect sync is not very great, as explained below.

Upon receipt of a packet addressed to the router, the interface 
checks for the presence of the sequence number and authentication 
tag. If absent, the packet is discarded. If present, the sequence 
number is matched against the receive window for the indicated 
sender. If the sequence number labels the packet as too old, or if it 
matches a flag in the window indicating that it is a duplicate, the 
packet is discarded. If the packet sequence number suggests that the 
packet would be acceptable if it is authentic, the tag is checked. 
The check is simple, i.e., the key for the indicate sender is used to 
generate a tag based on the sequence number in the packet. If the 
locally generated tag matches the one in the packet, the packet is 
forwarded to the management processor and the window is updated, 
otherwise the packet is discarded.

This simple mechanism rate limits management traffic that is 
forwarded to the router's management processor. Because of the 
one-way property of the function, an attacker should have a low 
probability of generating a legitimate sequence number-tag  pair, 
proportional to the size of the tag and assuming a suitably large and 
random key. Since the authentication tag is not bound to the packet, 
a MITM attack could strip a tag from a legitimate packet and attach 
it to a bogus packet, but he cannot do so at a rate greater than an 
authorized sender sends legitimate management packets.

A residual vulnerability arises in that a router might accept as 
valid a packet that was already accepted via another interface, 
serviced via a different line card, prior to a resync. This is not 
ideal, but if we periodically synch across cards, the window of 
vulnerability is 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 sender who is authorized to 
send to multiple interfaces. In general I expect this would be a 
small number.

There are a few open issues:
	- where to carry the sequence number and tag
	- how big is the sequence number and how big is the tag
	- how big is the key
	- what one-way function to use

Comments?

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

---

From: Mark Handley <[email-masked]>
Date: Thu, 17 Apr 2003 13:57:32 -0700

>	- what one-way function to use

What do you do about sequence number re-initialization?  If this is
being used to protect routing traffic, and a router restarts, do you
require stable storage to preserve the previous sequence numbers?

 - Mark

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Apr 2003 17:28:14 -0400

>require stable storage to preserve the previous sequence numbers?

Mark,

Good question.

At a minimum, stable storage is needed for the keys, but they change 
slowly, so maintaining that ought not be too hard. It would be harder 
for the per-sender window data to be saved, so we ought to have a 
plan for re-initialization.

A likely approach is to have the router that crashed initiate a 
connection to each authorized management entity to reinitialize, 
e.g., putting a new key in place and resetting the sequence number to 
zero. In the re-initialization process, the router would engage in a 
handshake with the management entities, using a nonce to ensure 
freshness, and because the router initiated the handshake, it can at 
least be protected against an attacker without access to the packets 
it sends as part of the re-initialization process. We may be able to 
be clever here too. For example, we could take the nonce generated by 
the router and use it as an input to generate the new key from the 
old key, so that the router and the management entity can very 
quickly transition to the new key and resume secure communication. 
I'll have to work out the details, but I think it's feasible with a 
quick UDP exchange.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 18 Apr 2003 00:00:02 +0200

On donderdag, apr 17, 2003, at 22:40 Europe/Amsterdam, Stephen Kent 
wrote:

> number which will be carried with the packet.

This is similar to something I proposed about a month ago:

"Ok, how about this: we use a stream cipher to come up with a 
random-looking
data stream on both ends and use the IPsec anti-replay counter as a
pointer to the part of the data stream that is used as a magic cookie in
the current packet. We can then program the line card with enough data
to be able to check a certain number of packets per session"

> For each authorized sender, the managed device maintains the following 
> information:

This means the crypto is done on the cards. Doing this beforehand 
elsewhere and then simply upload the results to the linecard is 
probably a better idea. A linecard with crypto hardware could of course 
do this on the fly but if we have such a linecard why not simply do 
IPsec AH?

> 	- a receive window consisting of the sequence number for the most 
> recent, valid management packet from the sender, a sequence number 
> indicating the edge for "too old" packets, plus a bit map marking 
> received , valid packets within the window.

I'm not sure requiring this bitmap is a good idea, as id adds 
complexity (that may need to be burnt into silicon).

> 	- where to carry the sequence number and tag

If we're doing IPsec, we already have the anti-replay counter that I 
think can easily do double duty here. For the tag we either have to 
create a completely new option or extend IPsec. Alternatively, the tag 
can be used as (part of) the IV for ESP processing.

> 	- how big is the sequence number and how big is the tag

The sequence number wraps all the time so 16 bits should be adequate or 
maybe 32 bits. As a typical window would be something like 64 packets, 
with a 32 bit tag an attacker has a one in 500 million chance of 
guessing a valid tag. A 10 Gbit link can carry several million packets 
per second so the attack would hit paydirt in a matter of minutes with 
32 bits. So I'd say at least 48 bits.

> 	- what one-way function to use

This is something the crypto experts should answer. I suspect that 
doing a one-way function over some static data and a sequence number 
doesn't provide enough entropy from one packet to the next to be 
secure, even for this purpose. My non-expert guess is that a stream 
cipher with the sequence number as a pointer to the stream would be 
better.

---

From: Mark Handley <[email-masked]>
Date: Thu, 17 Apr 2003 15:13:58 -0700

>If the management entity is a peer router at the other end of a link, 
>one might decide that less stringent resync mechanisms are needed, if 
>one does not assume a MITM attack capability.

I guess I think you need to assume MITM attack capability.  Routers
are quite often peered across LANs, and I wouldn't want to count on an
ethernet switch for routing protection.

 - Mark

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 18 Apr 2003 00:38:45 +0200

> ethernet switch for routing protection.

The question is whether we need to be able to do man in the middle 
protection at line rate. If a man in the middle needs a real packet for 
every forged packet, it would be ok for the line cards to let these 
packets through and let the CPU do the strong crypto to detect this.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Apr 2003 17:59:56 -0400

Mark,

I may have gone overboard in my proposed solution.

If the management entity is a peer router at the other end of a link, 
one might decide that less stringent resync mechanisms are needed, if 
one does not assume a MITM attack capability. Even for a management 
station the vulnerability associated with not changing to a new key 
immediately may be acceptable. The reasoning is that only if an 
attacker has saved old tags for this router can he now use them to 
send bogus messages that will pass the quick discard test. Once the 
management station reestablishes contact, using its sequence number 
(hopefully capable of being retained reasonably well), then the 
receive window is reset to the correct value and old messages are 
again excluded. So, one might choose to keep things simple and allow 
for a "dumb" restart, confident that in a short time the system will 
resync and become secure (against replay) again. Still, the 
management station would be wise to initiate a re-key when feasible.

Steve

---

From: Mark Handley <[email-masked]>
Date: Thu, 17 Apr 2003 16:22:10 -0700

>quickly transition to the new key and resume secure communication. 

I'm not sure I understand your solution, so let me see if I can
restate it.

Suppose I have two routers, A and B that were communicating securely.
Now, A restarts.  How is B going to accept any more packets from A, as
A can no longer send packets that fall in the window?

I think you implied (trying to fill in the details myself): 

 - A sends a re-initialization packet to B with nonce_A. 

 - B replies with nonce_A and a new nonce_B. 

 - A sends nonce_A and nonce_B back to B along with the new sequence
   number it wants to use and the one-way hash of nonce_A, nonce_B,
   the new sequence number and the secret.

 - On success, B sends nonce_A and nonce_B back to A, the new sequence number
   specified by A, and the one-way hash of nonce_B (but not nonce_A to
   avoid replay) the new sequence number and the secret.

On success, the new secret becomes the hash of the old secret and the
two nonces.

The reason for the last phase is to avoid a DoS vulnerability from
someone who can see traffic from A to B.  They can flood A with
re-initialization replies giving many different values of nonce_B.
Router A will have to respond to all of them to reliably set up
communication.  So we need to add a final phase so A unambiguously
knows which one was successful.  Also need to be careful not to be
used as an oracle - I think the above is OK, but I may have missed
something.

Is this more or less what you had in mind?

 - Mark

---

From: Mark Handley <[email-masked]>
Date: Thu, 17 Apr 2003 16:23:29 -0700

>packets through and let the CPU do the strong crypto to detect this.

That's true. But you've got to be careful in any re-initialization
mechanism to not allow the attacker use a MITM attack to de-sync
genuinely re-initializing peers so they can't communicate further,
while at the same time defending against flooding of the
re-initialization mechanism.

 - Mark

---

From: Damir Rajnovic <[email-masked]>
Date: Fri, 18 Apr 2003 08:32:35 +0100

Hi,

> - A sends a re-initialization packet to B with nonce_A. 

If you send nonce_A and H(secret, nonce_A) you will ensure that router A
is authenticated because (by the definition) only A knows the secret.
The router A can also offer a new sequence number in the same packet.
To make guessing even harder we can say that the router A should
send H(secret, nonce_A, new_seq_A).

By sending only nonce_A you are forcing the router B to respond to
any request it receives. It does not have any means to discriminate
which requests are legitimate and which are not. By sending a hash
in the first packet you can authenticate the sender.

> - B replies with nonce_A and a new nonce_B. 

B can reply with nonce_A, nonce_B, new sequence B and H(secret,
nonce_B, new_seq_B) and H(secret, sequence A+1). The first hash
H(secret, nonce_B, new_seq_B) server to initialize the new
sequence number for the reverse session (from A to B). The second
hash, H(secret, seq_A+1) is used normally as envisaged. The router
A will check it first to determine if it will accept the packet
or not.

I think that you can accomplish the same result with only two
messages instead of four. Since all data are sent in the clear
the strength of the protection lies in the one-way hash function
and the shared secret.

These steps could probably be abandoned.

>On success, the new secret becomes the hash of the old secret and the

Even using the modified handshake you can derive the new key in the
same manner. A and B are mutually authenticated and H(secret, nonce_A,
nonce_B) was never transmitted.

Gaus
==============
Damir Rajnovic <[email-masked]>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There are no insolvable problems. 
The question is can you accept the solution?

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 08:33:35 -0400

At 12:00 AM +0200 4/18/03, Iljitsch van Beijnum wrote:
>On donderdag, apr 17, 2003, at 22:40 Europe/Amsterdam, Stephen Kent wrote:
>
>>My new suggestion in this area requires a shared secret (key) 
>>between the router and the entity sending the management traffic, 
>>either another router or a management workstation. The key is one 
>>of two inputs to a one-way function; the other input will be a 
>>sequence number which will be carried with the packet.
>
>"Ok, how about this: we use a stream cipher to come up with a random-looking

I don't recall seeing your message on RPSEC. Also, it's still a bit 
hard to translate what you said above, into a more general 
description of the sort I provided, complete with a rationale of why 
it might suffice. Some stream ciphers are slow to compute an 
arbitrary value in the stream, vs. the "next" value, so the 
description you have above is more specific that my general proposal 
(in specifying stream ciphers) but it still needs to be narrowed to 
select the right sort of one-way function.

>probably a better idea. A linecard with crypto hardware could of 
>course do this on the fly but if we have such a linecard why not 
>simply do IPsec AH?

One could pre-compute sequence number/tag values and download them to 
line cards, but I would suggest this only if the function was too 
slow to effect in real time on the cards. There is a big difference 
between doign what I suggested and doing AH. The integrity check in 
AH covers most of the packet and thus will take longer to compute 
than a function that has only a key and a sequence number as inputs. 
Also, the AH integrity check skips some but not all IP header fields, 
making it complex to compute. So, this is an "apples/oranges" sort of 
comparison!

>>marking received , valid packets within the window.
>

Huh? You refer to the IPsec sequence number management mechanism in 
your quote, but the use of a bit map to track arrived packets within 
the window is exactly the nominal implementation approach for this, 
as described in RFC 2406 & 2406. What did you mean when you referred 
to IPsec sequence number management?

>create a completely new option or extend IPsec. Alternatively, the 
>tag can be used as (part of) the IV for ESP processing.

Yes, if we use IPsec for end-to-end security, one could definitely 
use that sequence number field, but I didn't know if people wanted to 
make that assumption for this mechanism.

>The sequence number wraps all the time so 16 bits should be adequate 
>or maybe 32 bits. As a typical window would be something like 64 
>packets, with a 32 bit tag an attacker has a one in 500 million 
>chance of guessing a valid tag. A 10 Gbit link can carry several 
>million packets per second so the attack would hit paydirt in a 
>matter of minutes with 32 bits. So I'd say at least 48 bits.

Recall that for IPsec we moved to support 64 bit sequence numbers 
(vs. 32 bit numbers) to better accommodate high speed links, so I a 
32 bit sequence number is probably the smallest I would consider, and 
64 would be preferable. The tag size is a crypto issue, as well as 
the key size, so all of these parameters need to be considered as a 
whole.

>cipher with the sequence number as a pointer to the stream would be 

Yes, let's not play cryptographer here.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 08:35:51 -0400

>ethernet switch for routing protection.

OK. As a security guy I'm accustomed to thinking in terms of MITM 
attacks, but I didn't want to impose my biases on the problem space.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 08:44:25 -0400

At 12:38 AM +0200 4/18/03, Iljitsch van Beijnum wrote:
>protection at line rate. If a man in the middle needs a real packet 
>for every forged packet, it would be ok for the line cards to let 
>these packets through and let the CPU do the strong crypto to detect 
>this.

Yes that is exactly the rationale underlying why it seems to be OK to 
not tie the authentication tag to the packet.

But, I interpreted Mark's comment to be a response to the question of 
what sort of attacks we have to worry about under restart conditions, 
where I suggested that we could relax the constraints after a crash 
where the sequence number info was lost.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 09:16:24 -0400

Mark,

Right.  My off the cuff protocol should be viewed just as a starting 
point for discussion, but this is a generally tricky area, because 
it's hard to defend against attacks that focus on DoS, and 
initialization is hard, and ...

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 09:25:09 -0400

>in the first packet you can authenticate the sender.

Very good point.

Do we need to choose a new sequence number, rather than  just 
starting at 0 again? I guess we get some benefit from a new sequence 
starting point in terms of rejecting old or random traffic faster, 
assuming that the attacker does not have passive wiretap ability 
(often true, but not always).

>the strength of the protection lies in the one-way hash function

Right. And, this hash function need not be the same as the function I 
called for using to generate per-packet tags. This hash function 
could be slower, since it is used less frequently.

>nonce_B) was never transmitted.

I like the style of your proposed exchanges. The goals of the (re) 
initialization protocol are to put in place a new secret and, maybe, 
to reset the sequence number and to minimize the opportunities for an 
attacker to waste router resources in the process.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 09:28:59 -0400

Mark,

I like the suggestions Damir made, to include data in each message to 
make forgery hard and thus allow a router to reject bogus 
re-initialization attempts.

When I dashed off the quick message late yesterday afternoon I was 
thinking more about the router-to-management station case, where 
there is less of a need to worry about processing for bogus 
re-initialization messages. The router-to-router case was not 
foremost on my mind. But, it is nice to have a unified way to deal 
with both cases and I think we are heading in that direction.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 18 Apr 2003 16:52:37 +0200

> hard to translate what you said above, into a more general description 
> of the sort I provided, complete with a rationale of why it might 
> suffice.

It was part of a more extensive discussion, but I agree your 
description is more thorough and more general.

> Some stream ciphers are slow to compute an arbitrary value in the 
> stream, vs. the "next" value, so the description you have above is 
> more specific that my general proposal (in specifying stream ciphers) 
> but it still needs to be narrowed to select the right sort of one-way 
> function.

Of course.

> line cards, but I would suggest this only if the function was too slow 
> to effect in real time on the cards.

Even if you _can_ do it on the fly, that doesn't mean it is preferable 
to do it that way. The whole point of the earlier stuff I mentioned 
above was to not have to do crypto for each incoming packet, but rather 
for each expected valid packet. This should be doable in software, or 
with the assistence of crypto hardware without the requirement that 
this crypto hardware be able to keep up with line rate on all 
interfaces.

> There is a big difference between doign what I suggested and doing AH. 
> The integrity check in AH covers most of the packet and thus will take 
> longer to compute than a function that has only a key and a sequence 
> number as inputs. Also, the AH integrity check skips some but not all 
> IP header fields, making it complex to compute. So, this is an 
> "apples/oranges" sort of comparison!

Yes, but if you have a perfectly good apple tree, is a craving for the 
occasional orange reason enough to build a green house so you can grow 
them?

In other words: yes, your integrety check is cheaper than full AH, but 
is it worth the trouble to implement a new protocol in hardware? If I 
were buying crypto hardware, I'd rather have it do full line rate IPsec.

>> 'm not sure requiring this bitmap is a good idea, as id adds 

> the window is exactly the nominal implementation approach for this, as 
> described in RFC 2406 & 2406. What did you mean when you referred to 
> IPsec sequence number management?

I don't think I mentioned the management of the sequence number, just 
the replay counter field. Having the bitmap processing would be a good 
feature, I'm just not sure it's a good idea to require it. Let the 
implementers worry about this.

> Yes, if we use IPsec for end-to-end security, one could definitely use 
> that sequence number field, but I didn't know if people wanted to make 
> that assumption for this mechanism.

Currently IPsec ESP supports authentication and encryption, maybe this 
could be an additional IPsec service?

> Recall that for IPsec we moved to support 64 bit sequence numbers (vs. 
> 32 bit numbers) to better accommodate high speed links, so I a 32 bit 
> sequence number is probably the smallest I would consider, and 64 
> would be preferable.

Note that the requirements here are very different from those in 
regular IPsec. In IPsec, data rates may be very high, and the overhead 
in creating a new SA is considerable. In this scheme, the data rates 
are in the order of one Mbps or less and the overhead of increasing the 
window is very small. So there is no need to support a large sequence 
number space, a simple sliding window pointer is sufficient. Even 6 
bits could be enough. The other end can simply fill in the missing bits 
to arrive at the desired sequence number length.

> The tag size is a crypto issue, as well as the key size, so all of 
> these parameters need to be considered as a whole.

It's not a traditional crypto issue. After thinking about it a bit more 
I realized my earlier reasoning that the tag should be at least 48 bits 
doesn't hold. With a 32 bit tag an attacker has a 1 in 4 billion chance 
of guessing a valid tag/sequence combination. Even with millions 
abusive packets per second that means the CPU only gets to see a hand 
full per hour. That's more than adequate. And a smaller tag has the 
advantage that it makes analysis by an attacker more difficult, I think 
there are some remarks about this in one of the IPsec documents on 
authentication.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Apr 2003 16:08:46 -0400

At 4:52 PM +0200 4/18/03, Iljitsch van Beijnum wrote:
>
>>One could pre-compute sequence number/tag values and download them 
>>to line cards, but I would suggest this only if the function was 
>>too slow to effect in real time on the cards.
>
>Even if you _can_ do it on the fly, that doesn't mean it is 
>preferable to do it that way. The whole point of the earlier stuff I 
>mentioned above was to not have to do crypto for each incoming 
>packet, but rather for each expected valid packet. This should be 
>doable in software, or with the assistence of crypto hardware 
>without the requirement that this crypto hardware be able to keep up 
>with line rate on all interfaces.
>
>>There is a big difference between doign what I suggested and doing 
>>AH. The integrity check in AH covers most of the packet and thus 
>>will take longer to compute than a function that has only a key and 
>>a sequence number as inputs. Also, the AH integrity check skips 
>>some but not all IP header fields, making it complex to compute. 
>>So, this is an "apples/oranges" sort of comparison!
>
>Yes, but if you have a perfectly good apple tree, is a craving for 
>the occasional orange reason enough to build a green house so you 
>can grow them?

Must be an old Dutch proverb ?

>In other words: yes, your integrety check is cheaper than full AH, 
>but is it worth the trouble to implement a new protocol in hardware? 
>If I were buying crypto hardware, I'd rather have it do full line 
>rate IPsec.

No disagreement about what would be ideal, just a matter of 
complexity and cost, which I have been told are concerns for some 
folks :-)

>>your quote, but the use of a bit map to track arrived packets 
>>within the window is exactly the nominal implementation approach 
>>for this, as described in RFC 2406 & 2406. What did you mean when 
>>you referred to IPsec sequence number management?
>
>I don't think I mentioned the management of the sequence number, 
>just the replay counter field. Having the bitmap processing would be 
>a good feature, I'm just not sure it's a good idea to require it. 
>Let the implementers worry about this.

Yes, the implementation details are a local matter.

>
>>>If we're doing IPsec, we already have the anti-replay counter that 
>>>I think can easily do double duty here. For the tag we either have 
>>>to create a completely new option or extend IPsec. Alternatively, 
>>>the tag can be used as (part of) the IV for ESP processing.
>
>>use that sequence number field, but I didn't know if people wanted 
>>to make that assumption for this mechanism.
>
>Currently IPsec ESP supports authentication and encryption, maybe 
>this could be an additional IPsec service?

ESP mandates support for confidentiality plus integrity, or integrity 
only, or confidentiality only. Since the IPsec WG is trying to 
simplify the range of options, we're dropping mandatory support for 
confidentiality only. I don't see it as likely that we would add an 
"authentication tag not tied to the payload" option.

>>>The sequence number wraps all the time so 16 bits should be 
>>>adequate or maybe 32 bits. As a typical window would be something 
>>>like 64 packets, with a 32 bit tag an attacker has a one in 500 
>>>million chance of guessing a valid tag. A 10 Gbit link can carry 
>>>several million packets per second so the attack would hit paydirt 
>>>in a matter of minutes with 32 bits. So I'd say at least 48 bits.
>
>>32 bit sequence number is probably the smallest I would consider, 
>>and 64 would be preferable.
>
>regular IPsec. In IPsec, data rates may be very high, and the 
>overhead in creating a new SA is considerable. In this scheme, the 
>data rates are in the order of one Mbps or less and the overhead of 
>increasing the window is very small. So there is no need to support 
>a large sequence number space, a simple sliding window pointer is 
>sufficient. Even 6 bits could be enough. The other end can simply 
>fill in the missing bits to arrive at the desired sequence number 
>length.

Yes, legitimate management traffic should arrive at relatively low 
data rates, so maybe a smaller sequence number size would suffice. 
But, the tag size should be big enough to not allow an attacker to 
flood the system with bogus packets for which a non-trivial number 
pass this test.

>It's not a traditional crypto issue. After thinking about it a bit 
>more I realized my earlier reasoning that the tag should be at least 
>48 bits doesn't hold. With a 32 bit tag an attacker has a 1 in 4 
>billion chance of guessing a valid tag/sequence combination. Even 
>with millions abusive packets per second that means the CPU only 
>gets to see a hand full per hour. That's more than adequate. And a 
>smaller tag has the advantage that it makes analysis by an attacker 
>more difficult, I think there are some remarks about this in one of 
>the IPsec documents on authentication.

A tag formed from a truncated hash function output has the advantage 
that an attacker is not able to see all the output bits to try to 
work backwards to the key. But, we have not yet specified the 
function we will use to generate the tag, and so it's a bit premature 
to talk about whether a truncated output from that unspecified 
function is appropriate :-).

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 19 Apr 2003 19:46:39 +0200

> No disagreement about what would be ideal, just a matter of complexity 
> and cost, which I have been told are concerns for some folks :-)

They are. Maybe we'll see hardware that can do line rate crypto in some 
places in the forseeable future, for instance at the edges to protect 
against denial of service. But I'm pretty confident most people will 
not be happy doing line rate crypto on a 40 Gbps linecard just to 
protect a 1 Mbps max BGP session.

> "authentication tag not tied to the payload" option.

Does it make sense to reinvent the wheel here? Especially as we can at 
least reuse the anti-replay counter and possibly borrow some space from 
the initialization vector to store the tag. Obviously this mechanism 
would be entirely optional.

> that an attacker is not able to see all the output bits to try to work 
> backwards to the key. But, we have not yet specified the function we 
> will use to generate the tag, and so it's a bit premature to talk 
> about whether a truncated output from that unspecified function is 
> appropriate :-).

Agree. I was just pointing out that a bigger tag isn't necessarily 
better.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Apr 2003 21:30:59 -0400

At 7:46 PM +0200 4/19/03, Iljitsch van Beijnum wrote:
>...
>>ESP mandates support for confidentiality plus integrity, or 
>>integrity only, or confidentiality only. Since the IPsec WG is 
>>trying to simplify the range of options, we're dropping mandatory 
>>support for confidentiality only. I don't see it as likely that we 
>>would add an "authentication tag not tied to the payload" option.
>
>Does it make sense to reinvent the wheel here? Especially as we can 
>at least reuse the anti-replay counter and possibly borrow some 
>space from the initialization vector to store the tag. Obviously 
>this mechanism would be entirely optional.

Well, having invented this particular wheel, I am comfortable saying 
that the sequence number and windowing mechanisms should be reused, 
but nothing else :-)
We're not really reinventing here; we're reusing that mechanism.

More seriously, the focus of this proposal is a rate limiting 
authentication mechanism, and that is not very closely aligned with 
the security services that IPsec offers. So I do not think it likely 
that we will add this sort of facility, even as an option, to AH or 
ESP (said the editor of those documents).

Finally, the really hard problem we face is the (re)initialization 
protocol. This is a difficult problem to solve, since we want to 
minimize the opportunity for DoS attacks at both ends (so that we can 
use this between routers, not just between a management station and a 
router), to a greater extent that existing protocols like IKE (v2).

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 Apr 2003 10:44:14 +0200

On woensdag, apr 23, 2003, at 03:30 Europe/Amsterdam, Stephen Kent 
wrote:

>> at least reuse the anti-replay counter and possibly borrow some space 
>> from the initialization vector to store the tag. Obviously this 
>> mechanism would be entirely optional.

> that the sequence number and windowing mechanisms should be reused, 

Any particular reason for this?

> the security services that IPsec offers.

The phrase "rate limiting authentication mechanism" isn't clearly 
defined (or I'm unaware of this definition) but if you mean something 
that can effectively rate limit unauthentic traffic to very low levels 
without impacting authentic traffic, we are in agreement. Now obviously 
we can't immediately rule out any synergy between the simple 
authentication mechanism and the full-fledged one that IPsec 
provides... And in practice I think it's safe to assume (or mandate) 
that the new scheme will always be used together with ESP 
authentication or AH.

> So I do not think it likely that we will add this sort of facility, 
> even as an option, to AH or ESP (said the editor of those documents).

I don't care all that much what goes in which document, but I'd hate to 
see this take up unneeded space in the headers. Also, the hardware 
builders are probably not going to like this as option processing uses 
up silicon. This wouldn't be a problem for linecards implementing this, 
but the packets must also be forwarded using the fast path in routers 
that don't implement this, unless we can be positive that packets 
containing this option never traverse any routers in the middle. (Which 
we can't for iBGP.)

> router), to a greater extent that existing protocols like IKE (v2).

Does IKE have explicit support for negotiation in the presence of DoS?

I guess what we need for this is for the two endpoints to establish 
some bootstrapping authentication state without actually communicating. 
This should be doable in the presence of a pre-shared key for this 
purpose along with something that changes over time in a predictable 
way (such as the clock...).

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Apr 2003 13:41:46 -0400

At 10:44 AM +0200 4/23/03, Iljitsch van Beijnum wrote:
>On woensdag, apr 23, 2003, at 03:30 Europe/Amsterdam, Stephen Kent wrote:
>
>>>Does it make sense to reinvent the wheel here? Especially as we 
>>>can at least reuse the anti-replay counter and possibly borrow 
>>>some space from the initialization vector to store the tag. 
>>>Obviously this mechanism would be entirely optional.
>
>>Well, having invented this particular wheel, I am comfortable 
>>saying that the sequence number and windowing mechanisms should be 
>>reused, but nothing else :-)
>

Yes, as I noted, ESP or AH compute integrity checks over payloads, 
whereas ll we need for rate limiting is a function computed over a 
secret value and a sequence number. That means that we can perform a 
much faster computation, with an equivalent level of security 
(relative to working back to find the key). Thus it makes sense to 
explore this approach vs. just saying "implement a line-rate capable 
IPsec chip on each interface."

>defined (or I'm unaware of this definition) but if you mean 
>something that can effectively rate limit unauthentic traffic to 
>very low levels without impacting authentic traffic, we are in 
>agreement. Now obviously we can't immediately rule out any synergy 
>between the simple authentication mechanism and the full-fledged one 
>that IPsec provides... And in practice I think it's safe to assume 
>(or mandate) that the new scheme will always be used together with 
>ESP authentication or AH.

Agreed.

>I don't care all that much what goes in which document, but I'd hate 
>to see this take up unneeded space in the headers. Also, the 
>hardware builders are probably not going to like this as option 
>processing uses up silicon. This wouldn't be a problem for linecards 
>implementing this, but the packets must also be forwarded using the 
>fast path in routers that don't implement this, unless we can be 
>positive that packets containing this option never traverse any 
>routers in the middle. (Which we can't for iBGP.)

Only the destination router needs to look at these values, not 
intermediate routers.

>>minimize the opportunity for DoS attacks at both ends (so that we 
>>can use this between routers, not just between a management station 
>>and a router), to a greater extent that existing protocols like IKE 
>>(v2).
>
>some bootstrapping authentication state without actually 
>communicating. This should be doable in the presence of a pre-shared 
>key for this purpose along with something that changes over time in 
>a predictable way (such as the clock...).

IKE embodies mechanisms to make IT less susceptible to certain forms 
of DoS attacks. ESP is engineered to be able to process packets in a 
fashion to minimize opportunities for DoS, but not to the extent that 
we are discussing here.

It's not that the endpoints ought not communicate to establish fresh 
state (that would be a neat trick!). rather, we want the 
communication to be such that the responder to a re-init request to 
expend minimal effort, to avoid using this sort of request as yet 
another form of DoS. We can ensure (via an extra round trip) that we 
are having an exchange with a live partner (to reject replays) and we 
can ensure that after doing a crypto operation that the partner is 
who it claims to be.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 25 Apr 2003 21:49:47 +0200

> IPsec chip on each interface."

I agree here, but that's not that I was getting at. What I meant was 
that it makes sense to somehow make this new scheme part of the larger 
world of IPsec rather than create a new, independent protocol that 
handles this.

>> to see this take up unneeded space in the headers. Also, the hardware 
>> builders are probably not going to like this as option processing 
>> uses up silicon. This wouldn't be a problem for linecards 

> Only the destination router needs to look at these values, not 

I talked to some vendors at the IETF meeting in Atlanta and they told 
me that due to the fact that customers demand filtering on TCP/UDP port 
numbers on all interfaces, their IPv6 ASICs must support following the 
protocol chain to find the TCP/UDP header, and for this they must know 
about all the intermediate option headers to some extent, even though 
the router isn't supposed to look at these. This means that having 
"strange" options in an IPv6 packet will make said packet take the slow 
(software) path.

So if you want to implement an IPv6 option, be sure to consult with a 
good number of vendors first to make sure you're not shooting yourself 
in the foot. Hopefully this problem will go away at some point but I 
gather it's very real now.

I just now realized that we might be talking IPv4 and not IPv6 here.  
:-)

Another way to do this what would work in both IPv4 and IPv6 is 
encapsulate the whole thing in UDP...

>>> protocol.

>> key for this purpose along with something that changes over time in a 
>> predictable way (such as the clock...).

> state (that would be a neat trick!). rather, we want the communication 
> to be such that the responder to a re-init request to expend minimal 
> effort, to avoid using this sort of request as yet another form of 
> DoS. We can ensure (via an extra round trip) that we are having an 
> exchange with a live partner (to reject replays) and we can ensure 
> that after doing a crypto operation that the partner is who it claims 
> to be.

However, if a box goes down and the correspondent is still doing 
accelerated pre-authentication, the session re-establishement packets 
probably won't make it through to the CPU. NOT having the pre-auth 
isn't an attractive option as an attacker can now saturate the path to 
the CPU.

But maybe we don't really have to solve this. Would it be extremely 
hard to implement a feature that automatically stops traffic being 
_routed_ towards a router or management station if the management or 
routing session with this station is down? (Locally source packet 
should still be allowed through so sessions can be reestablished.)

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Apr 2003 16:22:15 -0400

At 9:49 PM +0200 4/25/03, Iljitsch van Beijnum wrote:
>that it makes sense to somehow make this new scheme part of the 
>larger world of IPsec rather than create a new, independent protocol 
>that handles this.

OK, I understand. Let me say why I think it is very unlikely for that 
to happen. IPsec is trying to remove complexity from implementations, 
whereas adding this functionality would add complexity. Moreover, the 
rate-limiting goal for this mechanism is not one that the IPsec WG, 
or most IPsec customers, see as relevant to the overall set of 
security features that IPsec offers. Thus I doubt that IPsec would 
add this feature.

>
>>>I don't care all that much what goes in which document, but I'd 
>>>hate to see this take up unneeded space in the headers. Also, the 
>>>processing uses up silicon. This wouldn't be a problem for 
>>>linecards implementing this, but the packets must also be 
>>>forwarded using the fast path in routers that don't implement 
>>>this, unless we can be positive that packets containing this 
>>>option never traverse any routers in the middle. (Which we can't 
>>>for iBGP.)
>
>I talked to some vendors at the IETF meeting in Atlanta and they 
>told me that due to the fact that customers demand filtering on 
>TCP/UDP port numbers on all interfaces, their IPv6 ASICs must 
>support following the protocol chain to find the TCP/UDP header, and 
>for this they must know about all the intermediate option headers to 
>some extent, even though the router isn't supposed to look at these. 
>This means that having "strange" options in an IPv6 packet will make 
>said packet take the slow (software) path.
>
>So if you want to implement an IPv6 option, be sure to consult with 
>a good number of vendors first to make sure you're not shooting 
>yourself in the foot. Hopefully this problem will go away at some 
>point but I gather it's very real now.

OK. Then we just need to be defined as "not strange" :-)

>I just now realized that we might be talking IPv4 and not IPv6 here.  :-)
>

yes, that might be an option.

>
>>>>Finally, the really hard problem we face is the 
>>>>(re)initialization protocol.
>
>>>I guess what we need for this is for the two endpoints to 
>>>establish some bootstrapping authentication state without actually 
>>>communicating. This should be doable in the presence of a 
>>>pre-shared key for this purpose along with something that changes 
>>>over time in a predictable way (such as the clock...).
>
>>It's not that the endpoints ought not communicate to establish 
>>fresh state (that would be a neat trick!). rather, we want the 
>>another form of DoS. We can ensure (via an extra round trip) that 
>>we are having an exchange with a live partner (to reject replays) 
>>and we can ensure that after doing a crypto operation that the 
>>partner is who it claims to be.
>
>accelerated pre-authentication, the session re-establishement 
>packets probably won't make it through to the CPU. NOT having the 
>pre-auth isn't an attractive option as an attacker can now saturate 
>the path to the CPU.
>

since a correspondent does not always know when its peer has crashed 
and recovered, our goal is to have a way to re-initialize without 
involving the CPU, to avoid the problems you cite.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Apr 2003 17:21:42 +0200

> whereas adding this functionality would add complexity.

Ok, not doing this is less complex than doing it. The real question is 
whether implementing the pre-authentication is more complex with or 
without IPsec. I think it could very well be the former.

>> good number of vendors first to make sure you're not shooting 

> involving the CPU, to avoid the problems you cite.

Re-initialize without involving the CPU... Talk about neat tricks!

Detecting failures is usually done with periodic keepalives. I don't 
see why this can't work here.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Apr 2003 17:53:08 -0400

At 5:21 PM +0200 4/28/03, Iljitsch van Beijnum wrote:
>>>I agree here, but that's not that I was getting at. What I meant 
>>>was that it makes sense to somehow make this new scheme part of 
>>>the larger world of IPsec rather than create a new, independent 
>>>protocol that handles this.
>
>>OK, I understand. Let me say why I think it is very unlikely for 
>>that to happen. IPsec is trying to remove complexity from 
>>implementations, whereas adding this functionality would add 
>>complexity.
>
>Ok, not doing this is less complex than doing it. The real question 
>is whether implementing the pre-authentication is more complex with 
>or without IPsec. I think it could very well be the former.

I don't see why you say this. The only thing we are reusing from 
IPsec is the anti-replay mechanism.  The authentication tag is not 
really related to what we do in AH or ESP.

>
>>>So if you want to implement an IPv6 option, be sure to consult 
>>>with a good number of vendors first to make sure you're not 
>>>shooting yourself in the foot. Hopefully this problem will go away 
>>>at some point but I gather it's very real now.
>

Well, as you suggested, the best bet is probably to encapsulate the 
traffic, so that intermediate systems do not see any reason to 
examine the packets more closely.

>
>>>But maybe we don't really have to solve this. Would it be 
>>>extremely hard to implement a feature that automatically stops 
>>>traffic being _routed_ towards a router or management station if 
>>>the management or routing session with this station is down? 
>>>(Locally source packet should still be allowed through so sessions 
>>>can be reestablished.)
>
>>since a correspondent does not always know when its peer has 
>>crashed and recovered, our goal is to have a way to re-initialize 
>>without involving the CPU, to avoid the problems you cite.
>

Your observation suggests a possible, hybrid approach. For peer 
router management communication (e.g., BGP), one could rely on higher 
level detection of failure as a precursor to initiating a response to 
a resynch message. But for management communication between a router 
and a management station, where we don't have as good info about 
router status, we might be more willing to process a resynch, because 
the management station has the resources to devote to this.

Steve