Subject: [anonsec] next task, applicability statement

From: kent at bbn.com (Stephen Kent)
Date: Wed, 1 Jun 2005 11:37:53 -0400

At 6:11 PM -0500 5/31/05, Nicolas Williams wrote:
>On Tue, May 31, 2005 at 10:45:37AM -0400, Stephen Kent wrote:
>[...]
>>  The answer was mixed, in that some ISPs use MD5, and other do not.
>>  Among those who do not, the primary reason cited as NOT the
>>  administrative burden of managing the keys (in the absence of an
>>  automated key management scheme), but rather the fear that use of the
>>  scheme created a DoS vulnerability for routers. Specifically, an
>>  attacker could send a moderate amount of bogus traffic that claimed
>>  to be for an MD5 protected BGP session, and this would invoke the
>>  additional computational burden associated with such protection. This
>>  perception on the part of network operators suggests that use of
>>  IPsec for this purpose is not going to be any more palatable than
>>  MD5, unless we have good arguments to counter the DoS concern cited
>>  by these operators.
>
>[...]
>
>>  I mention this because one of the major motivations cited by Joe in
>>  the BOF was precisely protecting e-BGP sessions against active
>>  attacks, e.g., resets.
>
>It was, yes, but there are other uses too, plus use between routers has
>hardly been ruled out.  Surely you don't think we should just conclude
>this WG and go home...
>
>Nico
>--

I do not mean to suggest that the possible invalidation of one of the 
several proposed rationales for BTNS should cause BTNS to dissolve. 
But, I recall that this specific motivation was used to justify 
adopting IPsec as the basis for BTNS, vs. SSL/TLS, because of the 
need to protect BGP sessions against spurious TCP RESETs. If we 
decide that BGP session protection is not likely to be effected via 
IPsec, unless the DoS concerns are addresses to the satisfaction of 
ISPs, then we might revisit the decision that IPsec is the candidate 
protocol to be used for BTNS.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 1 Jun 2005 11:37:23 -0400

Joe,

>If IPsec processing cannot be offloaded to line cards and run at rate,
>then it is doomed as a security mechanism.

There are many places in a network where one may choose to employ 
IPsec, with different benefits. Routers have not been designed to run 
IPsec on line cards, and this is not surprising. I would not 
criticize either IPsec nor router vendors for the current state of 
affairs.  After all, IPsec was not proposed as a hop-by-hop 
protection mechanism for subscriber traffic. Although we made 
accommodations in 2401bis to allow such use in overlay nets, largely 
at your insistence, that is not a primary application of IPsec.

>This is why I originally
>proposed investigating ways to make IPsec less strong but keep pace with
>line rate, without overloading the processor, but that was nixed by a
>number of parties in San Diego.

My recollection is that several folks said that the performance 
arguments put forth for why IPsec was not more widely deployed did 
not match their experience as implementors. I think it fair to say 
that the issue here is one of economics, not fundamental technical 
issues. Line cards come in various flavors and contribute 
substantially to the overall cost of a router, today. Since most 
routers are sold to enterprise (not ISP) customers, it's hard to 
argue why inclusion of IPsec on line cards is attractive to these 
customers.

>All competing solutions - the RST/ACK challenge being proposed in TCPM,
>TTL-225, even assuming SPI values can substantially help filter - all
>are equivalent to weaker encryption algorithms, where the weakest is a
>"cookie" that must be guessed, next are cookies in ranges, etc.

I agree that the underlying threat model being assumed here is one in 
which the attacker does not have passive or active wiretap 
capabilities for the link between a pair of routers. I have argued 
that this is not a good basis for security standards, but that is the 
model adopted by the ISPs. Remember, I have proposed use of IPsec as 
a component of the S-BGP architecture for several years, so this is 
not the sort of response from ISPs that I like to hear. But, I am 
passing it on because it was a clear message at this workshop, and 
relevant to one of the cited motivations for choosing IPsec as the 
protocol to be adapted to accommodate BTNS requirements.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/anonsec/attachments/20050601/8b167e9c/attachment.html

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 1 Jun 2005 11:05:05 -0500

> protocol to be used for BTNS.

I was asking for BTNS-like IPsec features long before the first ANONSEC
BoF.

The ANONSEC BoF had good timing, it brought together groups with
different uses for the same idea and reached critical mass.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Wed, 1 Jun 2005 13:09:01 -0400

Nico,
>different uses for the same idea and reached critical mass.

Yes, I agree. I noted to Sam at the close of the BoF, there appeared 
to be three different groups who wanted some set of overlapping 
features in IPsec to satisfy different criteria.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 01 Jun 2005 13:19:24 -0700

Stephen Kent wrote:
> There are many places in a network where one may choose to employ IPsec,
> with different benefits. Routers have not been designed to run IPsec on
> line cards, and this is not surprising. 

Cisco makes modules that, while not on line cards themselves, are
implemented in hardware (IPsec Services Modules).

> I would not criticize either
> IPsec nor router vendors for the current state of affairs.  After all,
> IPsec was not proposed as a hop-by-hop protection mechanism for
> subscriber traffic. Although we made accommodations in 2401bis to allow
> such use in overlay nets, largely at your insistence, that is not a
> primary application of IPsec. 

The issue of hop-by-hop ala RFC3884 is not related to BTNS; it wasn't
even cited in the original ANONsec ID.

e-BGP isn't hop-by-hop, it is communication TO the router, which is
already covered in 2401, since the host is terminating the traffic to a
local application and is thus acting as a host.

> My recollection is that several folks said that the_ performance_
> arguments put forth for why IPsec was not more widely deployed did not
> match their experience as implementors. I think it fair to say that the
> issue here is one of economics, not fundamental technical issues. Line
> cards come in various flavors and contribute substantially to the
> overall cost of a router, today. Since most routers are sold to
> enterprise (not ISP) customers, it's hard to argue why inclusion of
> IPsec on line cards is attractive to these customers.

Which is exactly why it would be useful to have low-cost (low-CPU power,
etc.) IPsec variants.

> which the attacker does not have passive or active wiretap capabilities
> for the link between a pair of routers. I have argued that this is not a
> good basis for security standards, but that is the model adopted by the
> ISPs. Remember, I have proposed use of IPsec as a component of the S-BGP
> architecture for several years, so this is not the sort of response from
> ISPs that I like to hear. But, I am passing it on because it was a clear
> message at this workshop, and relevant to one of the cited motivations
> for choosing IPsec as the protocol to be adapted to accommodate BTNS
> requirements.

That latter issue is moot; the reality is that IPsec is a good place to
develop BTNS for a variety of reasons independent of whether the result
is the more widely deployable compared to other protocols that might be
extended, as noted by Sam in Minneapolis when you raised this objection
before.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 01 Jun 2005 13:25:28 -0700

Stephen Kent wrote:
...
> protocol to be used for BTNS.

Protecting BGP sessions (i.e., TCP connections) against control attacks
(e.g., RSTs, ACK spoofing, etc.) requires a TCP or IP security
mechanism. SSL is insufficient to protect the TCP connection.

It is understantable that this presents a DOS attack, but so does any
algorithmic protection, even at the application layer. A multilevel
solution, with different levels of effort, would be (as always) useful.

Which is why, IMO, it'd be useful to have "cookie-mode" hashes,
header-only hashes, etc. - where a single packet might have multiple
levels of security applied:

	cookie : header-hash : full-hash

A packet thus protected could be triaged efficiently based on the
cookie, and only cookie-spoofers could generate load on the header-hash
level check.

Again, this argues for a variety of strengths of algorithms, which is
what FASTsec (the other half of what I proposed originally) is aimed at,
and which I continue to pursue outside the IETF (if anyone is interested)...

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 2 Jun 2005 11:34:50 -0400

At 1:19 PM -0700 6/1/05, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Stephen Kent wrote:
>>  Joe,
>>

yes, and there are good economic reasons that they are not on line cards.

>even cited in the original ANONsec ID.

But it the reason you seem to allude to in arguing that line-card 
implementations of IPsec are important.

>Which is exactly why it would be useful to have low-cost (low-CPU power,

As you'll see in my response to your other message, it is not at all 
clear that weakened variants of IPsec represent a good solution here.

>extended, as noted by Sam in Minneapolis when you raised this objection

My objection was valid then, and it is more relevant now because the 
primary rationale you cited for why IPsec is the right protocol for 
BTNS turns out to be a questionable assertion.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 2 Jun 2005 11:01:37 -0400

At 1:25 PM -0700 6/1/05, Joe Touch wrote:
>algorithmic protection, even at the application layer.

not true. I initiated discussion of this issue on the RPSEC list a 
while ago. We came to the conclusion that there is a reasonable way 
to address this specific sort of concern in a way that differs from 
what protocols like IPsec or SSL try to do.  Let me explain.

The goal in this context is to provide a rate limiting mechanism for 
control traffic, to minimize the possibility of overwhelming 
bandwidth or computation limited elements of a system. Because rate 
limiting is the goal, all one needs is a tag for each packet, readily 
checked by the receiver, that tells whether the packet is potentially 
legitimate and thus worthy of further examination. The tags need to 
be unpredictable by an adversary, but need not be bound to the 
packet, cryptographically. If an attacker strips a tag from a 
legitimate packet and attaches to a bogus packet, one would rely on a 
higher level security protocol to detect and reject the integrity 
violation. At worst, an attack of this sort results in one-for-one 
replacement of good packets with bad packets, and that is consistent 
with the rate limiting goal of the mechanism.

There are at least two other criteria one wants for the tags: they 
should be very fast to generate, and the receiver checking mechanism 
should be able to tolerate packet loss over reasonable windows. Thus 
some sort of RNG, with an ability to step forward for a modest 
length, quickly, is appropriate.  One also needs to be able to 
distribute and change the secrets shared between each transmitter and 
receiver, and to resync in the even of prolonged packet loss or loss 
of state by either end. Protocols for these functions pose another 
possible avenue of DoS attack, and so they need to be rate limited as 
well, via a different mechanism, e.g., a receiver might refuse to 
accept a purported resync packet from a specified source more than 
once per minute.

This analysis suggests that trying to use IPsec for BGP security, 
absent an underlying rate-limiting mechanism of the sort indicated, 
is probably not going to be acceptable. If the rate limiting 
mechanism were in place, then one could implement IPsec in the 
management processor, not on a lime card, and not worry about DoS 
issues. In fact, if an ISP didn't believe that the path traversed by 
management traffic were subject to MITM attacks (the threat model you 
proposed for BTNS), then they might not even bother with IPsec for 
BGP traffic, since the rate limiting scheme would reject bogus 
traffic generated off-link more efficiently!

>  A multilevel

What I describe above is a multi-layered approach, but one with a 
well understood division of security responsibility for each protocol.

>cookie, and only cookie-spoofers could generate load on the header-hash

I think the sort of mechanism I described represents a more secure 
foundation for the multi-layered defense we need. It is a 
cookie-style scheme in a sense, with no need for a hash to tie the 
cookie to any part of a packet, and thus it is more efficient and 
less prone to DoS.

>and which I continue to pursue outside the IETF (if anyone is interested)...

I think your proposal for faster algorithms of various strengths is 
another possible avenue, but it results in a more complex secure 
analysis when one tries to figure out what level of protection is 
afforded. By separating the rate-limiting mechanism from the 
authentication and integrity mechanisms we get an easier to 
understand set of security mechanisms, each of which can be evaluated 
independently for its targeted purpose.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 02 Jun 2005 09:23:58 -0700

> with the rate limiting goal of the mechanism.

That is exactly what I meant when I described 'cookie mode'; IMO, it'd
be useful to allow IKE to negotiate and potentially renegotiate these
cookies, as well as to check them at the IPsec level.

> accept a purported resync packet from a specified source more than 

There are varieties of cookies, agreed - some static (helps only with
off-path) and reused, some dynamic using RNGs, etc.

And agreed, IKE needs to be rate-limited as well.

> traffic generated off-link more efficiently!

The threat model includes off-path and on-path, FWIW.

However, the above is again why I believe the generic capability for
lower-quality algorithms is needed, independent of where.

However, they do need to be in the IPsec or TCP/"MD5" level to protect
connections; SSL does not protect the TCP connection, and since BGP
interprets TCP disconnects as signal-path failures, SSL is insufficient
to protect a BGP peer.

> well understood division of security responsibility for each protocol.

The division of security responsibility already lies in the selection of
the algorithm - authentication vs. encryption, e.g., as well as strength
of the algorithm. There's no need for a new protocol as much as for new
algorithms.

> cookie to any part of a packet, and thus it is more efficient and 

I don't care much about the specifics of the cookie algorithm - I'll let
others propose those. But I don't see how what you've discussed above is
different from what I proposed, other than I'm trying to use multiple
strengths within layers of use of a single protocol (IPsec, in this
case), whereas you are proposing entirely new protocols (??).

> independently for its targeted purpose.

Can you explain more about separating rate-limiting from authen/integ
mechanisms? Where is the rate limiting? (in 'IKE' or its equivalent?)

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20050602/998a6df3/signature-0001.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 02 Jun 2005 09:35:34 -0700

> yes, and there are good economic reasons that they are not on line cards.

Agreed, but when ISPs need the protection, there will be economic
reasons to include them, eventually. Just as forwarding moved onto line
cards, though not economical at first.

> implementations of IPsec are important.

I'm arguing that line cards are the input of packets - whether forwarded
or not, and that security triage needs to occur as early as possible.
That is irrespective of whether the packets are ultimately forwarded
(RFC3884) or terminated (e-BGP).

> clear that weakened variants of IPsec represent a good solution here.

What you described elsewhere are weakend variants of IPsec that just
don't use the IPsec header structure. Do we really need another
structure just for this purpose?

> BTNS turns out to be a questionable assertion.

I believe there are many things to fix with IPsec, and that BTNS and
FASTsec need to both be developed. I further believe that this addresses
the concerns of the ISPs you cited.

Sure, killing off half of that effort makes the use of IPsec to solve
e-BGP failures open to DOS attacks, but so does ANY use of high-effort
algorithmic security at any level. By this argument, ANY use of IPsec
with the current algorithms is doomed, and thus there's no reason to
avoid using IPsec for BTNS, since IPsec itself need not be considered
"holy".

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/anonsec/attachments/20050602/f366cb78/signature.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 2 Jun 2005 12:26:55 -0500

> cards, though not economical at first.

BTNS has several target consumers/uses as identified at the BoFs.

Stephen claims some of these don't want BTNS today, but that seems
hardly settled, nor is there reason yet to think that they won't want
BTNS later.  I see no reason yet not to proceed with an applicability
statement that mentions the use of BTNS by routers to protect BGP TCP
sessions against off-path attacks against TCP (and therefore BGP).

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 2 Jun 2005 13:53:01 -0400

>sessions against off-path attacks against TCP (and therefore BGP).

The use of the term "claim" here is pejorative, suggesting that I may 
be misrepresenting the facts. I reported what a set of ISPs stated in 
a workshop, a report of which will made made publicly available by 
DHS, just as they did for the first workshop.  Sorry you were not 
present to hear this for yourself, Nico.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 2 Jun 2005 14:30:45 -0400

Joe,

>(RFC3884) or terminated (e-BGP).

forwarding is the primary function of routers, so working to make it 
more efficient is an obvious router design goal. most folks believe 
that hop-by-hop protection of subscriber traffic is something a 
router should NOT do, so putting IPsec on line cards to provide this 
service is not an obvious design goal a router vendor.

>structure just for this purpose?

No, Joe, not even close. I suggest you re-read what I wrote. It is 
not at all IPsec-like, since it does not offer integrity or content 
authentication in MITM contexts, and it emphasizes rate limiting of 
traffic, a feature not present in IPsec.

>the concerns of the ISPs you cited.

I'm not sure how many share these beliefs :-)

>algorithmic security at any level.

no, I explained why your assertion is false in my previous message.

>By this argument, ANY use of IPsec

IPsec is not "holy," but it does represent the work of a lot of 
people over many years. It yielded standards that gave rise to a VPN 
industry and to a protocol that, with varying degrees of fidelity, is 
implemented in all mainstream operating systems, firewalls, etc.

If the justification for creating BTNS is to address unmet security 
requirements, then  BTNS should be free to satisfy these requirements 
using any protocol that meets the agreed-upon requirements.  In that 
case it is very important that the requirements be validated.

If, on the other hand, BTNS was created so that people could revise 
IPsec, unencumbered by the need to achieve consensus with the 
membership of the IPsec WG, then there may be less need to validate 
the requirements used to justify choices made by BTNS.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 2 Jun 2005 14:20:34 -0400

Joe,
...

>cookies, as well as to check them at the IPsec level.

If that's what you meant, it was not at all clear to me. Even the 
text you provided above talks about renegotiating cookies via IKE, 
rather than negotiating a shared secret used to generate a sequence 
of cookies. Maybe the problem we have trying to communicate, Joe, is 
translating between the terminology used in the security community to 
describe mechanisms and the terms of the sort you were using.

>off-path) and reused, some dynamic using RNGs, etc.

What you refer to as a static cookie is not only not secure if an 
attacker can wiretap a link, but it also provides much less 
protection, on a bit by bit basis, because it is unchanging, as 
compared to a sequence of pseudo-random values.

>And agreed, IKE needs to be rate-limited as well.

yes, whatever mechanism one uses for distribution and refresh of 
shared secrets needs to be rate limited, but that is an easier 
problem if the set of peers is limited and known a priori, as is 
typically the case for management traffic. (This of course is not the 
case for the BTNS context, where peers are not known a priori, and 
are not authenticated.) the mechanisms for rate limiting here are 
different, because you are not dealing with steady state 
communication.

>The threat model includes off-path and on-path, FWIW.

I distinctly recall you dismissing MITM attacks as part of the range 
of attacks that BTNS was intended to address, at the BoF, so I'm 
puzzled by this comment.

>lower-quality algorithms is needed, independent of where.

You have not provided a concrete example (that others have agreed 
with) to justify your suggestion for an algorithmically watered down 
IPsec. Since this topic is not within scope for BTNS, I suggest we 
not pursue it further.

>of the algorithm. There's no need for a new protocol as much as for new

I'm sorry, Joe, but you seem to be missing the point. rate limiting 
traffic in a bandwidth or computationally constrained context is a 
specialized security function that is not best addressed by watering 
down the crypto algorithms used with a security protocol, since such 
watering down degrades the other security services offered by the 
protocol.

>case), whereas you are proposing entirely new protocols (??).

Yes, it seems from the text above that you didn't understand what I 
proposed, and thus have trouble distinguishing it from mechanisms 
that perform crypto binding of cookies to headers, etc.

>mechanisms? Where is the rate limiting? (in 'IKE' or its equivalent?)

IKE, IPsec, and other security protocols we have developed in the 
IETF do NOT focus on rate limiting traffic in a computationally 
efficient fashion, so your second question is inappropriate.

The purpose of rate limiting is provide a very fast check on an 
arriving packet, so that a receiver need not apply more expensive 
checks at a rate higher than the rate at which peers send legitimate 
traffic.

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 2 Jun 2005 13:56:45 -0500

On Thu, Jun 02, 2005 at 01:53:01PM -0400, Stephen Kent wrote:
> be misrepresenting the facts.  [...]

I did not have this meaning in mind, I was trying to be concise but
failed to be precise.  I do trust your report, I just don't think it
adds up, yet, to sufficient evidence to discount Joe's use case for BTNS
(that proposition, not your report, is what I find hardly settled).

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 02 Jun 2005 12:14:30 -0700

> service is not an obvious design goal a router vendor.

It's something firewalls do, and routers aren't substantially different
from firewalls these days in what they need to perform.

...>>> As you'll see in my response to your other message, it is not at all
> traffic, a feature not present in IPsec.

It isn't IPsec/3DES or IPsec/MD5-like, but it can be implemented using
IPsec headers inside the IPsec architecture. IPsec may require certain
algorithms, but there's no reason not to add others.

> I'm not sure how many share these beliefs :-)

You brought up the ISPs, not me. The feedback you got from them implies
that they think that IPsec has this weakness.

> no, I explained why your assertion is false in my previous message.

I disagree, but see that message (shortly) for why.

> implemented in all mainstream operating systems, firewalls, etc.\

And isn't being used by ISPs to protect TCP connections for BGP.

> the requirements used to justify choices made by BTNS.

ANONsec was created to satisfy the requirements using any protocol; BTNS
is (IMO) an application of ANONsec to IPsec, because it is provides a
useful framework to develop these issues.

We already understand that you disagree as to how useful it is, or
whether there is implicit damage to the Holy IPsec as a result. But
that's not been seen by others here as a reason to avoid proceeding.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 02 Jun 2005 12:18:18 -0700

> describe mechanisms and the terms of the sort you were using.

As I said, the details of the cookie algorithm aren't important to me
per se; they could be static cookies negotiated by IKE, renegotiated by
IKE, or follow some sequence as you suggest.

It's not a matter of terminology as apathy - I want support for a
variety of these algorithms.

> compared to a sequence of pseudo-random values.

Yes, we all know that, but that sort of 'cookie' is basically what the
IP address and port pairs provide. It's similar enough to what the TCP
RST provides as well. The point isn't whether that's insecure for
on-path attacks, but whether it's low-effort and can help distinguish
packets for a preliminary level of triage.

Further, the cookie space can be larger than the IP address/port pair,
because it is decoupled from them.

It's not the only solution, but one of a variety that could be used,
depending on the threat model.

> different, because you are not dealing with steady state 

Doens't IKE need to be rate limited anyway? How does it matter if I know
the peers; I can still be flooded by attackers. Unless the 'permitted
peer' traffic is filtered based on IP addresses and ports, at which
point that's a cookie filter that works only for off-path attacks.

BTNS doesn't open up a hole with respect to IKE attacks; the number of
connections admitted can - and should - be limited anyway, just as it
would for a conventional IKE endpoint that is configured for a large
number of legitimate peers. There's still triage at some point either way.

> of attacks that BTNS was intended to address, at the BoF, so I'm 

MITM != on-path

MITM during the key exchange is what I dismissed. That's substantially
harder than just viewing packets on-path and injecting packets; there
are timing issues for MITM during key exchange to succeed.

> IPsec. Since this topic is not within scope for BTNS, I suggest we 

The concrete example is what you brought up - ISPs that don't want to
deploy IPsec because it provides a CPU-loading DOS attack. The solution
is to use any of a variety of watered-down algorithms within IPsec's
protocol.

I agreed that this wasn't within scope for BTNS when it was raised in
San Diego, and agree that it isn't worth pursuing - either within this
WG at this time, or as a reason not to use IPsec within this WG at this
time either.

> watering down degrades the other security services offered by the 

I don't buy that assertion; IPsec allows a variety of algorithms, not
all with the same strength. This is just a different set of algorithms
which can provide different computational effort and different
protection, just as 3DES is different from DES.

> that perform crypto binding of cookies to headers, etc.

As I've repeatedly said, the algorithm isn't the point; it's the
variety of algorithms that matters. IPsec already had two variants that
treated headers differently (AH and ESP), this would be a third (or
fourth, etc.).

There's no need to develop an entirely new framework in which to acheive
this - ESPECIALLY since, in order to be useful, the triage must occur
before stronger (e.g., 3DES) conventional IPsec. Which means it either
has to be inside the IPsec framework, or has to be at the IP level and
supercede it.

> efficient fashion, so your second question is inappropriate.

It's not my question, it was the ISPs. If you can't rate limit IPsec,
you have to rate limit a header outside of IPsec.

> checks at a rate higher than the rate at which peers send legitimate 

We all know the definition, but all such checks are relative. DES is a
rate limit check on 3DES.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 2 Jun 2005 17:31:30 -0400

Joe,

>from firewalls these days in what they need to perform.

Many firewalls have two interfaces, whereas most routers have more 
interfaces and hence more line cards. Firewalls are placed at 
well-defined security perimeters, by definition, whereas routers 
appear at many points in a network. There are a lot of differences 
that call into question the utility of your firewall/router analogy, 
with regard to this issue.

>algorithms, but there's no reason not to add others.

The purpose of the ICV in ESP or AH is to provide an integrity check 
for the covered payload, which is substantially different from the 
rate limitation feature I described. Changing the algorithm used here 
is not a good way to achieve a fundamentally different security 
function.

>that they think that IPsec has this weakness.

ISPs are the folks who explained why they did not use MD5, and why 
they would not use IPsec in this context. It is not a weakness of 
IPsec, anymore than one would call a screwdriver weak when used as a 
cold chisel. It is a matter of using an appropriate mechanism in a 
given context.

>And isn't being used by ISPs to protect TCP connections for BGP.

That statement, while true, is misleading, because no ISP can use 
IPsec for this purpose, since it is not offered for this purpose by 
router vendors. ISPs don't write code for routers. They configure 
what Cisco, Juniper, Avica, etc. offer. So, the first hurdle is for 
the router vendors to offer IPsec as an alternative to MD5 for BGP 
session protection. Then we can see if ISPs enable it. Given the 
concerns cited by ISPs re use of MD5, it is not clear that router 
vendors are scrambling to make IPsec available for this purpose, 
although that might change if we can address the DoS concern.

>useful framework to develop these issues.

ANONsec doesn't exist, except as a legacy mailing list name. BTNS is 
the WG that was approved. Thus discussion about the former seems 
irrelevant.

>that's not been seen by others here as a reason to avoid proceeding.

"We?" Is this the same "we" that does not agree with your rationale 
for a crypto-lite version of IPsec, or the "we" that disagrees with 
my suggestion that cited rationales for pursuing a course of action 
in a WG should be re-evaluated when they appear to be false?

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 2 Jun 2005 17:27:13 -0400

Joe,

>variety of these algorithms.

In the security business, details are what make systems secure or 
not, so those of us who do this professionally pay attention to 
details.

>point that's a cookie filter that works only for off-path attacks.

IKE embodies mechanisms that would allow it to rate limit new IKE 
SAs, even though such functionality is not specified. Such limiting 
could be done even in the face of MITM attacks, but it's viability 
depends on the context in which IKE is used. For router management 
traffic this would be fairly easy. I'd explain the details, but 
you've said that such details are not of interest ...

>number of legitimate peers. There's still triage at some point either way.

In the context we're discussing, router management traffic, the 
number of peers is not typically large, so the example you cite is 
not appropriate.

>are timing issues for MITM during key exchange to succeed.

yes, I think we all know MITM is on-path. The model you propose is a 
MITM who conveniently is asleep when the key exchange takes place, so 
that the unauthenticated exchange is secure enough.

>is to use any of a variety of watered-down algorithms within IPsec's

that's a very poor solution, because it trades off integrity for 
management traffic in order to avoid the DoS problem. Using a 
separate mechanism for rate limiting allows one to use good quality 
algorithms for integrity while avoiding the DoS concern.

>WG at this time, or as a reason not to use IPsec within this WG at this

What's the "this" you allude to here?

>protection, just as 3DES is different from DES.

sorry you don't see the difference, still.

>treated headers differently (AH and ESP), this would be a third (or

yes, you could define additional protocols to augment AH and ESP, or 
different algorithms, or both. the question is whether this is the 
right way to address the specific problem that you choose to cite as 
a justification for BTNS.

>has to be inside the IPsec framework, or has to be at the IP level and

Not quite true. If one implemented a rate limiting mechanism at the 
IP layer it could be independent of the use of IPsec. it would 
precede IPsec checking, if present, but it need not supercede it.

>you have to rate limit a header outside of IPsec.

no ISP sent the message, you did.

>rate limit check on 3DES.

the discussion we're having does not convince me that "we all know 
..." You keep citing encryption algorithms (e.g., DES), in the 
context of what you consider an integrity requirement, while I point 
out that an integrity-less mechanism will suffice.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 02 Jun 2005 15:06:32 -0700

> number of peers is not typically large, so the example you cite is 

You already said that there is IKE rate limiting, so it isn't relevant
either.

> that the unauthenticated exchange is secure enough.

MITM attacks during key exchange require either precise timing or
interception capability (not just snooping and injection in the latter
case). Either case is substantially more challenging attacks than just
on-path injection based on snooping.

> algorithms for integrity while avoiding the DoS concern.

I don't want to use JUST watered-IPsec; I want to use multiple layers of
IPsec.

And rate-limiting, as I noted elsewhere, must occur before the more
CPU-intensive versions of IPsec if it is to counter IPsec DOS traffic.
As I said, that requires either an IP security protocol outside IPsec to
protect via rate limiting, or the use of watered-IPsec outside the
regular IPsec. The former unnecessarily requires another IP security
protocol.

> What's the "this" you allude to here?

Increasing IPsec performance was raised in San Diego and agreed as not
part of BTNS; the use of that performance enhancement to deal with DOS
attacks was part of the current thread.

> sorry you don't see the difference, still.

I believe it is you who does not see the similarity, still. ;-)

> a justification for BTNS.

BTNS isn't designed to solve a specific problem other than the need for
pre-agreed keys (preshared or CA certs) to use IPsec. I explained that I
considered fixing this key issue a part of how to make IPsec useful to
e-BGP, but it isn't sufficient under DOS attacks - nor is IPsec in
general. That requires a different solution, but that's not the point of
BTNS.

I cited e-BGP as one place to use BTNS; the fact that your informal
survey of a set of operators suggest that they want more is an
indication that there is more to do, not less.

> precede IPsec checking, if present, but it need not supercede it.

If at the IP layer, it must occur on the outermost IP header - it
cannot, e.g., occur on the IP header inside an IPsec'd packet.

It supercedes it in that if rate limited, the packet would be dropped.
The check of IP rate limiting and IPsec needs to be not only ordered,
but short-circuited (which is why I chose supercede rather than just
precede, but you have issue with that, so let's skip the semantics
debate - we're agreeing on the concept).

But a deeper issue is why you - a security person - don't see rate
limitng as a security mechanism. Pure rate limiting isn't security, but
rate limiting based on a cookie - or dynamic variant thereof - IS. Which
is why I feel it would be better developed as an alternate algorithm in
the IPsec suite than as a completely separate protocol that
recapitulates IPsec.

> no ISP sent the message, you did.

It was you who raised the issue of ISPs and DOS attacks (thus the issue
of rate limiting), not I.

> out that an integrity-less mechanism will suffice.

s/DES/MD5/ and s/3DES/SHA/

It doesn't matter whether it's encryption or integrity - there is a need
for a variety of algorithms with a variety of CPU effort to support
multi-layered filtering as a rate-limiting mechansim.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 02 Jun 2005 15:25:13 -0700

Stephen Kent wrote:
> Many firewalls have two interfaces, 

And many do not; many are made from routers.

> whereas most routers have more 

Routers, augmented with additional filtering, are used as firewalls.
They are needed especially when there are different levels of 'outside',
i.e., different levels of trust.

> is not a good way to achieve a fundamentally different security 

A null algorithm provides a kind of cookie feature. That's a fine way to
achieve at least one variant.

IPsec already provides at least two different security functions
(encryption and integrity); why not three?

> cold chisel. It is a matter of using an appropriate mechanism in a 

The fact that IPsec doesn't support algorithms that are sufficiently
fast to use for multilevel DOS triage is a weakness, just as a fixed
screwdriver is weaker than a driver with multiple sized heads.

> although that might change if we can address the DoS concern.

Speaking of misleading, are you implying that Ipsec needs to be modified
to support BGP protection?

The existing IPsec on those routers can already be used to support
transport assocations for port 179. It's a matter of configuration, not
'enabling' a capability.

> the WG that was approved. Thus discussion about the former seems 

In the IETF, anonsec is just a mailing list name, but it doesn't cease
to exist as a concept just because a portion of the work is being done
under BTNS.

The ANONsec I am referring to above is the concept, and I raised it to
emphasise the point that BTNS _is_ the IPsec version of the keyless
security component of that concept. You brought up the point of
'choosing any protocol' to apply it to, and that's where that point
exists, not in BTNS.

> in a WG should be re-evaluated when they appear to be false?

It is the "we" who disagrees with your assertion that IPsec was chosen
solely because of the example rational, and the "we" that disagrees that
the lack of DOS support in IPsec is a reason not to fix keyless use of
IPsec because of anecdotal reports, even if "we" agree with those reports.

It is the "we" that isn't interested in debating whether the Holy IPsec
should be protected from BTNS and all other modifications that you do
not agree with.

Joe

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 3 Jun 2005 10:39:34 -0400

Joe,

This exchange is becoming a waste of our time, and probably an 
annoyance for the others on this list.  I'll respond to only one or 
your comments, because I think it illustrates the miscommunication 
that so often characterizes our e-mail exchanges.

>the IPsec suite than as a completely separate protocol that

I have characterized rate limiting of the sort I described as a 
security service, but one that is fundamentally different from 
watered down integrity checking. So your first sentence above makes 
no sense to me.

Adding the sort of rate limiting I described to IPsec as a separate 
protocol, in addition to AH and ESP, could be done. It would not be a 
complementary algorithm, analogous to HMAC or AES, which are choices 
for integrity and confidentiality. The service is intrinsically 
different from those that we now offer, so referring to is as an 
alternate algorithm confuses matters.

For example, we could create a new protocol, X, that one views as 
part of IPsec, and which effects the crypto-based rate limiting I 
described. The choice of algorithm for X becomes a matter of 
selecting a PRNG. The protocol would define a format for carrying the 
tag (or cookie, as you wish), and the procedures for verifying that 
the tag was valid, which includes rejecting replays and accommodating 
out of order packet arrival.

But, what would we have done, relative to the router management 
problem that we have discussed? If we say that X is another protocol 
in the IPsec suite, that where is it implemented in the router? If it 
is in the management processor, which I still maintain is the 
appropriate place for IPsec when used to protect BGP traffic, then we 
have not solved the problem, since if the traffic gets that far it is 
already too late.  This suggests that protocol X has to be 
implemented on a line card, to be effective. That's fine, but it 
suggests some potential complexity for IPsec since we have now 
required the implementation to be divided across the management 
processor and each line card, by making X part of IPsec. Also, if one 
wants integrity and authentication, not just the rate limiting 
service, one will need to use ESP or AH, and there will be two layers 
of IPsec protocols, since X is part of IPsec. TYhis adds complexity 
to SPD management, and raises the question of how to maintain the 
SAD, since it nominally needs to be accessed in both the line cards 
and the management processor.

So, unless we implemented IPsec on each line card, in which case we 
might not need the rate limiting service, making protocol X part of 
IPsec probably results in a very complex implementation. It also 
raises questions about how to define the IPsec boundary which now 
appears to be distributed across the router in various locations.

If, on the other hand, one addresses rate limiting with an IP option, 
for the steady state part of the problem, then many of these 
complications would not arise, and could make use of a simple IPsec 
implementation in the management processor.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Fri, 3 Jun 2005 11:26:40 -0400

Joe,

>And many do not; many are made from routers.

most commercial firewalls are designed for that purpose, not recycle 
routers. even the Cisco products that emphasize firewall capabilities 
differ from their products that focus on routing, and that are 
employed as border routers.

>i.e., different levels of trust.

As above, you may be viewing this more from an abstract perspective 
than a real product perspective.

>achieve at least one variant.

Null encryption and authentication algorithms exist in IPsec only 
because folks did not want to make a change to IKE v1 after we 
decided to allow for integrity-only ESP. Don't make them into 
anything more than an embarrassing terminology fix necessitated by an 
oversight in a protocol format.

>(encryption and integrity); why not three?

You could add another security service, in a new protocol that 
offered just this service, and make that protocol a part of IPsec. 
The question is whether the result is generally useful, especially if 
it necessitates additional layering of SAs. The alternative, which 
you did not clearly propose or reject, would be to cerate a new 
protocol that offered optional rate limiting, optional integrity, and 
optional confidentiality. A sort of ESP+. is that what you had in 
mind? It's clearly out of scope for BTNS.

>screwdriver is weaker than a driver with multiple sized heads.

By this reasoning, TCP is weak because it does not behave like UDP.

>to support BGP protection?

I cannot imagine what prompts this question, other than as a way to 
change the subject? Use of IPsec to protect BGP is appropriate only 
if we address the rate limiting of management traffic problem that 
plagues routers, and which encompasses more than BGP.

>transport assocations for port 179. It's a matter of configuration, not

Representatives from Cisco and Juniper both said that one could not 
configure IPsec to protect BGP sessions in their routers using 
current products, when asked by attendees at the first DHS routing 
security workshop, in mid March.

>security component of that concept.

"keyless?" I think you mean unauthenticated. Keys are still going to 
be out in place via IKE and used by AH or ESP, based on the charter I 
read. Sloppy  use of words that engender unnecessarily lengthy e-mail 
exchanges.

>IPsec because of anecdotal reports, even if "we" agree with those reports.

again, keyless? the sample rationale was precisely the one case cited 
as to why IPsec was the right choice. that is distinct from a 
statement on the part of others to use IPsec as the basis for new 
functionality, irrespective of the presentation of suitable rationale.

>should be protected from BTNS and all other modifications that you do

I guess those of us who have worked on IPsec for many years should be 
flattered to se it referred to as "Holy." It makes this discussion 
sound like an argument over an attempt to hijack a well recognized 
protocol name while changing the underlying functionality.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 03 Jun 2005 09:34:33 -0700

Stephen Kent wrote:
...
> watered down integrity checking. So your first sentence above makes 

Blind rate limiting is easy to implement, but impacts legitimate peers.
Differential rate limiting needs to separate traffic from legitimate
(with some false positives) traffic from non-legitimate (with no false
negatives).

IMO, differential rate limiting is a continuum, both in terms of the
rates limited to (full down to zero) and the strength of separation
(legitimate + false positives down to no false positives). Current IPsec
is one configuration of that set of knobs.

I.e,, ESP rate limits to 0 for things that fail SPI lookup, fail to
decrypt/authenticate, or fail to match ports, and "unlimits" the rate
for things that suceed.

There are certainly uses to other 'rates' than 100% and 0%, but IMO the
utility for reducing DOS impact is to use low-cost algorithms that have
higher percentages of false positives.

> alternate algorithm confuses matters.

IMO, it's just an algorithm of AH or ESP, just one that is weaker, e.g.,
MD4, down to ones closer to 'null'.

The current modes of IPsec already provide completely different
capabiltiies (integrity vs. encryption), and provide different strengths
of algs (MD5 being 'crackable', AES slower but no known cracks, etc.)

> out of order packet arrival.

If the format for carrying the tags is similar - as with integrity and
encryption - we don't need a new tag format.

> and the management processor.

I agree that there are complexities, but they remain whether there are
two protocols or one. If one, then we can describe how to manage the
complexities more easily.

I do believe that if IPsec is going to be used widely in routers -
either for management traffic or as VPN endpoints - this sort of
capability is needed anyway.

> appears to be distributed across the router in various locations.

IPsec on each line card still needs rate limiting to be widely deployed;
line-rate IPsec is expensive at best; using a variety of algorithms
would allow the cost to be reduced.

> implementation in the management processor.

My point is that the IP option solution is basically re-doing all of
IPsec - the databases, the key exchange protocol, even most of the
header formats, since we can't assume free option space in which to
operate. I see no reason to develop a new protocol that needs to be just
as coordinated with the internal IPsec anyway.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 03 Jun 2005 10:02:53 -0700

> employed as border routers.

Cisco, to pick a data point, makes three kinds of devices:

	- custom firewalls (5500 series)
	- firewall module for routers (FWSM)
		for their 6500 and 7600-series
	- firewall software for routers

I don't know what's faster - 5500 series custom devices or 7600-series
routers. I also don't have statistics on what is actually deployed
everywhere, but I do know a few universities (which are fairly large)
that use predominantly routers, not hardware firewall devices, to do
firewalling.

> oversight in a protocol format.

A null algoritm (note that I didn't refer to null mode, ala RFC2410)
could be used for cookie-based checks, where the SPI and subsequent port
checks are what is verified, but no other algorithm is used.

> mind? It's clearly out of scope for BTNS.

There are two security services offered by IPsec - integrity and
encryption, differed by the algorithms used. They both are supported in
both IPsec protocols - AH and ESP - as well as in IKE. I am proposing
other algorithms, closer in spirit to MD5/AES/3DES/SHA  than to AH/ESP.
I am proposing that although a different protocol could be developed, it
would be redundent with IPsec, so I would prefer it to be integrated.

Although I had proposed this work as possibly being part of BTNS
originally, I appreciate that this is out of scope, and I was not
proposing to bring it back.

It _is_ a separate effort at ISI, and I welcome others who would be
interested in collaborating, and may bring it to the IETF as a different
effort when appropriate.

> By this reasoning, TCP is weak because it does not behave like UDP.

TCP was weak because it supported congestion control but didn't support
window scaling, so we added that.

IPsec provides a number of things, including admission control. To the
extent that multilevel DOS triage is needed to support efficient
admission control, I believe it to be deficient.

> I cannot imagine what prompts this question,

The part where you tell us that routers can't support IPsec on BGP, as
per below.

...
> security workshop, in mid March.

There must be some adjectives missing, since I have done it with fairly
low-end Cisco products. Perhaps IPv6 BGP (IPv6 and IPsec aren't
concurrently supported in IOS yet)?

> as to why IPsec was the right choice.

Please review the notes. IPsec is a good choice because:

	- it protects the transport layer
		and avoids the need for per-transport protection
	- IKE and the SPDs are a good framework
		in which to develop this solution

I used BGP as one place the solution might be useful, and I still
believe it to be useful there; the concerns about DOS attacks need to be
addressed, but affect ALL algorithmic solutions anyway (SSL, TCP/MD5,
and IPsec), and only network and transport layer protection will
ultimately protect BGP (because of its interpretation of connection
interruption).

While there are other 'solutions' to off-path attacks, they all fail
with respect on-path attacks in ways that BTNS does not (except, as
noted, duing the brief window of IKE handshake, or for MITM).

As Nico noted, I don't believe we need a single example of overwhelming
a-priori willingness to deploy this solution to proceed, however.

Joe

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Sun, 5 Jun 2005 21:32:31 +0300

Dear Stephen and Joe,

While I find your recent discussion at the BTNS WG mailing
list interesting, I also think that a large part of it does
not belong to this WG.  Some of the issues seems be of
relevance, and most probably should be recorded somewhere in
the forthcoming applicability document.

However, what comes to the proposal to create a new protocol,
or variant of AH or ESP, that would provide some kind of an
early lightweight verification (tagging or cookies) to be
performed before AH or ESP integrity verification, that clearly
falls outside the scope of this WG, as I think you duly noted.
On the other hand, personally I find the proposal quite
interesting, and would suggest creating another mailing list
for it, and perhaps trying to schedule a BOF for either Paris
or Vancouver.  Hence, my co-chair allowing, I think that we can
continue this discussion here *temporarily*, until such a new
mailing list has been set up.

I think the included message below nicely highlights the points
that you both have in this regard, and might function well as
a starting point for such a discussion.  What comes to the
architectural difficulties w.r.t. IPsec, to me it seems that
there are such difficulties if you take rfc2401(bis) as such.
On the other hand, I think I understand Joe's desire to add
this kind of a new protection as a part of IPsec, and perhaps
re-use some of the existing security mechanisms.

Maybe there could be a middle path, where we would add a new
"sublayer" to the IPsec mechanisms?  Perhaps the new sublayer
could re-use the SPD and PAD but have an independent SAD, and
hence could be more easily implemented on separate hardware.

Perhaps something like the following:

                        Unprotected
                          ^       ^
                          |       |
            +-------------|-------|-------+
            |             |       |       |
            |             |       v       |
            |             |   +--------+  |
            |     +-----------| Prot.X |  |
            |     |       |   +--------+  |
            |     v       |       ^       |
            | +-------+   |       |       |
            | |Discard|<--|       V       |
            | +-------+   |B  +--------+  |
          ................|y..| AH/ESP |..... IPsec Boundary
            |   +---+     |p  +--------+  |
            |   |IKE|<----|a      ^       |
            |   +---+     |s      |       |
            | +-------+   |s      |       |
            | |Discard|<--|       |       |
            | +-------+   |       |       |
            +-------------|-------|-------+
                          |       |
                          V       V
                          Protected

--Pekka

On Jun 3, 2005, at 19:34, Joe Touch wrote:

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFCoIaZE5f5cImnZrsRArxhAJwLQMZ+2vmwYZhSy7+4enzCZZruRgCeNMZ3
> Xs8XPYcEXMdXY+av4tNuE50=
> =U4RU
> -----END PGP SIGNATURE-----
> _______________________________________________
>

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 6 Jun 2005 10:55:01 -0400

Pekka,

I'm glad we agree that this is out of scope for BTNS.  I disagree 
that it is an appropriate extension to IPsec, in the form of a new 
protocol, at least in the router context that motivated the 
discussion.  I will send you the message I was about to send to the 
list, noting the reasons that this is not such an attractive option. 
I will not send the message to the list, so as to not perpetuate this 
exchange.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 6 Jun 2005 10:56:35 -0400

Joe,

The short form summary of your message is:

	- you believe that rate limiting should be effected via weak 
integrity algorithms and use of sequence numbers, vs. a separate 
mechanism that decouples integrity from crypto-based rate limiting. 
you provide no good analysis of why this should be true.

	- you characterized MD5 as "crackable" in protocols such as 
ESP & AH, but MD5 is used there in the HMAC construct, so your 
characterization seems an exaggeration, at best.

	- you believe routers really should implement IPsec on line 
cards, even though this is not generally viewed as an appropriate 
security mechanism for subscriber traffic protection by most folks 
(except, perhaps, if the router is functioning as an SG for an 
enterprise), and it is clearly an unduly expensive implementation 
strategy for protecting router management traffic.

	- you believe that the AH or ESP format should be reused for 
rate limiting, which implies a minimum of an 8 byte overhead in 
addition to the cookie/tag/ICV. this is about double the overhead 
that would be required for a rate limiting scheme of the sort I 
suggested.

	- you appear to believe that devices used as VPN endpoints 
will be the same as border routers, although product design criteria 
would suggest otherwise.

I could go on, but as I said before, this is probably not a good use 
of anyone's time.

Steve

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 6 Jun 2005 10:59:24 -0400

Joe,

>checks are what is verified, but no other algorithm is used.

Reread 2410. It defines an algorithm, not a mode, as per IPsec/IKE terminology.

>encryption,

the second service is confidentiality; encryption is the mechanism by 
which the service is provided. all the IPsec specs are very 
consistent in this regard.

>differed by the algorithms used.

the services differ not only in terms of the algorithms employed, but 
also the data that is protected by them. for example, the SPI and 
sequence number are almost always integrity protected, and never 
encrypted.

>  They both are supported in
>both IPsec protocols - AH and ESP - as well as in IKE.

No, AH does not offer confidentiality or employ encryption.

>  I am proposing

AH and ESP are protocols, not algorithms.

>would be redundent with IPsec, so I would prefer it to be integrated.

the text above confuses security services with mechanisms, includes 
misstatements about which services are offered by which protocols, 
confuses IPsec modes vs. algorithms and algorithm modes, and 
protocols vs. algorithms. so it's hard for me to know what you really 
mean when you refer to a different protocol in the sentence 
immediately above.

>IPsec provides a number of things, including admission control.

nowhere does this term appear in the IPsec specs. do you mean access control?

>concurrently supported in IOS yet)?

The response was not related to IPv6.. Are you saying that you have 
Cisco routers that run BGP and that you have configured them to 
protect BGP sessions with IPsec as offered internally by the routers? 
You say that IOS does not support IPsec, but that, presumably, is 
where IPsec would have to be supported to allow it to be used to 
protect a BGP session terminating at the management processor in a 
router of suitable size for use as a border router.

Steve

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Jun 2005 08:22:03 -0700

Corrected as below:

> mechanism that decouples integrity from crypto-based rate limiting. you
> provide no good analysis of why this should be true

As you provide none that this is not.

>     - you characterized MD5 as "crackable" in protocols such as ESP &
> AH, but MD5 is used there in the HMAC construct, so your
> characterization seems an exaggeration, at best

The reports of crackability of MD5 are well-known; it was an
illustrative example that some algorithms are stronger than others.

>     - you believe routers really should implement IPsec on line cards,
> even though this is not generally viewed as an appropriate security
> mechanism for subscriber traffic protection by most folks (except,
> perhaps, if the router is functioning as an SG for an enterprise), and
> it is clearly an unduly expensive implementation strategy for protecting
> router management traffic.

I believe that routing devices - including firewalls - should implement
IPsec on line cards for VPNs, as a SG.

Protection of router management traffic requires that the management
processor can filter whathever traffic is directed to it at whatever
rates it can enter the device. That means pushing filtering checks out
to the edges - on the line cards - regardless of whether it's IPsec or
another algorithm.

>     - you believe that the AH or ESP format should be reused for rate
> limiting, which implies a minimum of an 8 byte overhead in addition to
> the cookie/tag/ICV. this is about double the overhead that would be
> required for a rate limiting scheme of the sort I suggested.

I believe that AH and ESP are already used for rate limiting - to two
rates. I further believe that 8 bytes of overhead is negligible; we use
20 for tunnels all over the place without significant concern.

>     - you appear to believe that devices used as VPN endpoints will be
> the same as border routers, although product design criteria would
> suggest otherwise.

I cited specific products that support this capability, offered by
Cisco, and two examples of large university enterprises that provide
firewalling using those routers.

I agree that this is out of scope for BTNS.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Jun 2005 08:37:22 -0700

> Reread 2410. It defines an algorithm, not a mode, as per IPsec/IKE

Read my MAIL. I never said RFC2410, whether referring to the mode or the
algorithm.

> which the service is provided. all the IPsec specs are very consistent
> in this regard.
> 
> sequence number are almost always integrity protected, and never encrypted.

Agreed - but that is not a difference in integrity or confidentiality;
that is a difference in how portions of the packet are necessarily
protected differently under both variant.s

> No, AH does not offer confidentiality or employ encryption.

But ESP does offer either.

> AH and ESP are protocols, not algorithms.

Read the sentence again; that's what I said

> confuses IPsec modes vs. algorithms and algorithm modes, and protocols
> vs. algorithms. so it's hard for me to know what you really mean when
> you refer to a different protocol in the sentence immediately above.

Although different protocols could be developed as alternatives to AH or
ESP, in different architectures than IPsec (which itself conruses
mechanisms with architectures), there's no need per se.

ESP could be used, given different algorithms than MD5/SHA/3DES/AES, to
provide filtering for rate limiting.

> nowhere does this term appear in the IPsec specs. do you mean access

Yes.

> Cisco routers that run BGP and that you have configured them to protect
> BGP sessions with IPsec as offered internally by the routers? You say
> that IOS does not support IPsec,

IOS does not support IPv6 and IPsec at the same time (it was suggested
for performance reasons, encouraging the use of coprocessors rather than
just software). IOS does support IPv4 and IPsec, and that can be used to
protect BGP ports.

> but that, presumably, is where IPsec
> would have to be supported to allow it to be used to protect a BGP
> session terminating at the management processor in a router of suitable
> size for use as a border router.

IPsec for large border routers should be supported in hardware, and is
via coprocessors. Terminating the IPsec there is fine; once it's in the
box, it's in the box.

Joe

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Jun 2005 09:10:24 -0700

> the forthcoming applicability document.

Those two statements seem inconsistent; if it's part of the AS, then we
need to vet it out on this list, though it would be useful to hear other
viewpoints as well.

> mailing list has been set up.

I'd be glad to set that up at postel.org, if there is a good name for
such a list - maybe "triage"?

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Mon, 6 Jun 2005 21:39:13 +0300

Joe,

> need to vet it out on this list, though it would be useful to hear 

While I think that some specific points from your discussion
should be recorded, such as the potential performance problems
related to IPsec processing in routers and especially the potential
of DoS against router management processors, many other aspects
of the discussions are, according to my judgement, clearly beyond
the WG charter.  For example, a proposal of early verification/
tagging/cookies of IP packets clearly does not belong to this WG.
(But, OTOH, I do think that such tagging may well be a good idea.)

Hence, if you want to continue discussing the specific residual
threats of using BTNS to (partially) protect router management
traffic, that _does_ belong to this list, but if you want to discuss
how to solve those residual threats with mechanisms that go beyond
anonymous or unauthenticated keying, then that is outside the scope
of the WG.

> such a list - maybe "triage"?

Personally, I don't think that the list name matters much.  The
list charter is probably more important.  Personally, I'd like
us to focus mostly on the problem first, i.e., the potential DoS
that especially on-path but possibly also off-path attackers may
pose to the IPsec integrity verification process.  The solution
could be anything from a partially-redesigned ESP to a new
IP extension header or even maybe reuse of some existing fields
in some existing headers.  But given that,  I would suggest
something like Tagging IP Packets for Protecting Integrity
Protection (TIPPIP) :-)  But, as said "triage" as a list name is
also fine for me.

--Pekka Nikander

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 06 Jun 2005 13:18:42 -0700

> anonymous or unauthenticated keying, then that is outside the scope

Sure. Just clarifying.

> Protection (TIPPIP) :-)  But, as said "triage" as a list name is

I'll setup the list today and announce it later.

Joe