Subject: [anonsec] Milestone to be filled: Decision on whether SPD/PAD extensions are needed

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 11 May 2005 17:31:43 -0400

I think that at a minimum we need a way of saying that a particular
SPD entry can be a BTNS entry.

I'm not entirely sure what the PAD implications are, but I'm quite
certain we need at least a bit in the SPD.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed, 11 May 2005 17:04:23 -0500

> SPD entry can be a BTNS entry.

Why?  You should be able to determine this from the address selectors of
the SPD entries in conjunction with the PAD.  I.e., given an SPD entry
you can find matching PAD entry(ies) and determine which peers are BTNS
peers that way.

In fact, an SPD entry might match all peers, BTNS or otherwise, so
marking SPD entries as somehow related to BTNS seems wrong.

> certain we need at least a bit in the SPD.

My I-D [1] describes the PAD extensions that I think are necessary.

In the BITS case the PAD entries for BTNS peers must associate addresses
with BTNS IDs.

In the native mode IPsec case we could get away with not having a
persistent PAD for BTNS peers as each "socket" or even each datagram
read/write event, and therefore the _application_ could deal in BTNS
IDs, thus saving the PAD the bother.

But even in the native mode IPsec case we may care for persistent PAD
entries for some BTNS peers, either made in a leap-of-faith manner or
else explicitly by applications (perhaps after performing authentication
and channel binding).

So, IMO, the PAD needs extending in the BITS and native mode cases, and
the SPD does not.

[1]  http://www.ietf.org/internet-drafts/draft-williams-btns-unauthenticated-bits-00.txt

Nico
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 11 May 2005 23:28:17 -0400

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Wed, May 11, 2005 at 05:31:43PM -0400, Sam Hartman
    Nicolas> wrote:
    >> I think that at a minimum we need a way of saying that a
    >> particular SPD entry can be a BTNS entry.

    Nicolas> Why?  You should be able to determine this from the
    Nicolas> address selectors of the SPD entries in conjunction with
    Nicolas> the PAD.  I.e., given an SPD entry you can find matching
    Nicolas> PAD entry(ies) and determine which peers are BTNS peers
    Nicolas> that way.

Because the SPD is designed to specify the system security policy of
the system.  Specifying whether a particular policy entry requires
authentication materially affects the security assumptions for that
policy.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 12 May 2005 11:08:01 -0500

> authentication materially affects the security assumptions for that

The 2401bis model relies on the PAD for specifying how authentication is
done.  The connection between SPD and PAD is the addresses of the
packets that match the SPD entries, as the addresses are the key into
the PAD.

Or, at least, that's how I understand it.

Nico
--

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 12 May 2005 13:19:04 -0400

Nicolas,

I agree with Sam here. The SPD embodies the description of access 
control policy, and the PAD is the linkage to key management, so that 
we have a way to constrain the range of IDs that we are willing to 
accept from  a peer, and then use for lookup of SPD entries.

That said, I have not read your I-D to see what you proposed in 
detail, so maybe I'll come to a different conclusion afterwards :-).

Steve

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 12 May 2005 12:38:14 -0500

> accept from  a peer, and then use for lookup of SPD entries.

I can see now that it could be useful to be able to reference a peer's
BTNS or non-BTNS status in the SPD (see below), but I don't see it as
absolutely necessary.

The PAD, according to 2401bis, describes how to authenticate peers.

BTNS peers might be "authenticated" by using public key values as IDs,
but that is still, in a way, authentication, and so policies like:
"10.100.1/24 use BTNS" or "10.100.1.23 is a BTNS peer using public
key ID value XYZ" belon in the PAD.

Now, to then allow all BTNS peers only access to, say, DNS, then the SPD
can reference those addresses...  But I see now that that could get
unwieldy!

> detail, so maybe I'll come to a different conclusion afterwards :-).

Please do.  I do now think that an SPD extension would indeed be useful.
But the PAD extensions described in my I-D are also necessary.

Nico
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Thu, 12 May 2005 13:59:32 -0400

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:

    Nicolas> On Thu, May 12, 2005 at 01:19:04PM -0400, Stephen Kent
    Nicolas> wrote:
    >> Nicolas,
    >> 
    >> I agree with Sam here. The SPD embodies the description of
    >> access control policy, and the PAD is the linkage to key
    >> management, so that we have a way to constrain the range of IDs
    >> that we are willing to accept from a peer, and then use for
    >> lookup of SPD entries.

    Nicolas> I can see now that it could be useful to be able to
    Nicolas> reference a peer's BTNS or non-BTNS status in the SPD
    Nicolas> (see below), but I don't see it as absolutely necessary.

It's not absolutely necessary to create an implementation I agree.  I
think it is necessary to preserve the access control model of IPsec
and to keep policy defined in the SPD.

---

From: kent at bbn.com (Stephen Kent)
Date: Thu, 12 May 2005 14:18:39 -0400

>The PAD, according to 2401bis, describes how to authenticate peers.

The PAD text in 2401bis says that the PAD does two things:
	- how to authenticate a peer, which certainly suggests that a 
PAD extension to represent a peer's status re BTNS will be essential
	- what type and range of IDs the peer is authorized to 
represent, which is essential to preventing an authenticated (or 
unauthenticated) peer from asserting an ID for lookup in the SPD when 
that peer is not authorized to do so

Steve

---

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Fri, 27 May 2005 13:18:43 +0300

[Chairing]

Folks,

Having read the discussion about whether SPD/PAD extensions are
needed, I'd interpret the WG opinion as follows:

   - SPD extensions (at least one bit) is needed to retain
     the IPsec semantics; alternatively, even though it may
     be possible (at least in some cases) to derive that
     information from the PAD, storing the information in the
     SPD would be useful anyway

   - PAD extensions are clearly needed

Given the above, my interpretation is that we do need both
SPD and PAD extensions in practise.  At this point of time
I don't think it matters, in practise, why exactly we need
SPD extensions; i.e., whether it is necessary to retain the
IPsec semantics or just useful.

As such, I consider the WG having reached consensus on this
and our first milestone to be fulfilled.

If you don't agree with this, please indicate so now, latest
on June 3rd.

---

Our next milestone is now the first version of the problem
and applicability statement.  Joe Touch and David Black are
working on that, me helping.  The plan is to proceed fast
with that, and have it WG LCd before Paris.

--Pekka

---

From: kent at bbn.com (Stephen Kent)
Date: Tue, 31 May 2005 10:45:37 -0400

Folks,

I attended a DHS workshop on routing security in Seattle, May 18-19. 
A number of ISPs were represented at the workshop, which took place 
immediately after the NANOG meeting in Seattle.  One of the topics 
discussed was "do you use the TCP/MD5 checksum to secure e-BGP 
sessions, and if not, why not?"

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.

Note that the MD5 processing was not, per se, the fundamental 
problem, although it contributed to the problem. Rather, any moderate 
amount of traffic that cannot be filtered by line cards and that 
appears to be management traffic, will often be sufficient to 
overwhelm the management processor on a router, thus leading to the 
DoS concern. MD5 protection for BGP traffic just makes this generic 
problem worse.

One might argue that use of IPsec could ameliorate this problem 
because an attacker would need to be able to guess the SPI for 
protected traffic, and if a line card could be configured to look a 
very limited set of currently valid SPIs, then this traffic could be 
filtered quickly and efficiently. However, we were advised that even 
such simple checks as the TTL-255 hack were not implementable on some 
routers, until ASIC changes are effected. That suggests that 
filtering on a non-IP header value that charges over time (as opposed 
to the simple IP header check for a TTL value of 255 o 254 for 
traffic addressed to the router itself) may not be easy to implement 
in many deployed routers.

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.

Steve

---

From: shep at alum.mit.edu (Tim Shepard)
Date: Tue, 31 May 2005 13:08:43 -0400

> filtered quickly and efficiently. However, we were advised that even 

An attacker could also flood you with IKE requests too, so your IKE
implementation would also have to be hardened to defend against DOS
attacks, particularly to not burn cycles doing modular exponentiation
for illegitimate requests.   How to sort the legitimate requests from
the illegitimate requests is a thorny problem.

			-Tim Shepard
			 shep at alum.mit.edu

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 31 May 2005 16:01:25 -0700

> the BOF was precisely protecting e-BGP sessions against active 

If IPsec processing cannot be offloaded to line cards and run at rate,
then it is doomed as a security mechanism. 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.

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 believe that BTNS is a step in the right direction - relieving key
management concerns from IPsec deployment - and will ultimately benefit
more than just e-BGP, esp. as it becomes easier to guess address/port
pairs either by exhaustion, prediction, or snooping. However, it won't
solve all impediments to IPsec deployment, and performance and latency
are the other two that remain on my list, whether in the IETF or elsewhere.

Joe

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 31 May 2005 18:11:34 -0500

On Tue, May 31, 2005 at 10:45:37AM -0400, Stephen Kent wrote:
[...]
> MD5, unless we have good arguments to counter the DoS concern cited 

[...]

> the BOF was precisely protecting e-BGP sessions against active 

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
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 31 May 2005 16:11:26 -0700

FWIW, regarding the title of the thread, I am drafting the AS right now,
just as a status.

PS - It seems like IPsec would help compared to TCP/MD5, as the former
is often supported via line card hardware, whereas the latter isn't (or
at least that's my impression - can anyone with router hardware
experience speak to that?)

Joe