Subject: [anonsec] Automatic detection of BTNS capability

From: ekr at rtfm.com (Eric Rescorla)
Date: Mon, 14 Mar 2005 08:12:41 -0800

Post the BOF in MSP, I've been thinking about how BTNS works in
practice. In particular, do you want to be able to use it with hosts
that you don't already know support IPsec in some flavor (either
traditional or BTNS), but fall back to plaintext if it's not
available. If the answer is yes, then you're faced with the question of
how you detect whether the peer implements IPsec. [0]

The obvious approach is simply to do the traditional IPsec thing and
hold the initial packets until the IKE handshake has completed. However,
if the peer doesn't do IKE and has firewalled off that port, then you're
stuck waiting for the timeout. This really delays the initiation of the
connection.

The other option is to start sending traffic right away and do the
IKE handshake in parallel. Then if the IKE handshake completes you
switch over. Obviously, this makes sense in the face of the
"no active attacks" assumption, but it seems like a fairly substantial
change to the IPsec model...

-Ekr

[0] This isn't a problem with traditional IPsec because if your policy
requires protection, you won't be able to communicate with non-IPsec
hosts anyway.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 14 Mar 2005 11:32:08 -0600

> how you detect whether the peer implements IPsec. [0]

We want this to be an option.

Note that Joe's requirements are that active attacks are only possible
at first, that after a successful initial exchange MITMs no longer work.

A downgrade attack is an active attack that BTNS can't defend against
except through policy, or interfaces, which disallow fallback onto
unauthenticated plaintext.

> stuck waiting for the timeout. This really delays the initiation of the

If you're willing to fallback on unauthenticated plaintext, which should
not be a default.  Otherwise this is no worse than IPsec is today.

> change to the IPsec model...

No, I don't think we want this -- I don't, anyways.  Joe?

But note that BTNS has other implications as well.

Assuming BITS implementations the only way to avoid MITM attacks
subsequent to the initial exchange is to make a persistent {IP addr,
pubkey} association -- like secsh leap-of-faith -- and that may have
implications for mobile networking.

> requires protection, you won't be able to communicate with non-IPsec

Right.

Nico
--

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Mon, 14 Mar 2005 13:17:49 -0500

> change to the IPsec model...

yes, though I believe the some of the opportunistic IPsec folk may already 
have running code for the latter model.

There are clearly possible hybrid models: 
 - give IKE a short time to claim the traffic; after that, send cleartext 
	until an SA arrives (which may never happen).
 - if others to initiate BTNS to us, use it in reply -- but we always
	initiate in the clear/never initiate any connection (pure server).
 - if we know a BTNS key for the peer, try harder.
	- have history via ssh-style initial-leap-of-faith
	- ipseckey or equivalent in DNS
	- ???
 - "allow BTNS" and "require BTNS" modes can be made compatible.

the above is intended as food for thought.  pruning will be needed to 
keep our scope manageable.

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 10:53:40 -0800

> On Mon, Mar 14, 2005 at 08:12:41AM -0800, Eric Rescorla wrote:
...
> No, I don't think we want this -- I don't, anyways.  Joe?

IMO, that doesn't make sense (I agree with Nico). It'd be like using IKE 
but passing traffic until you do IKE - you don't do that now, you 
wouldn't with BTNS.

> implications for mobile networking.

Yes - if you change your IP address, and don't do something to hide that 
from IPsec (e.g., use a tunnel over the parts that change), then you'd 
have to reassociate with the new addresses.

Mobility already breaks lots of things when renumbering; BTNS is not new 
in this regard. BTNS doesn't add anything to that discussion, so IMO it 
is sufficient to ignore that issue as BTNS-specific.

>>requires protection, you won't be able to communicate with non-IPsec

You decide if you want to require BTNS or use it where it's available. 
In the first case, you drop all attempts that don't handshake in IKE.

In the second, you drop packets until IKE succeeds or fails, and notify 
the app (a flag that it would be able to check). Apps that care can put 
up a "locked padlock" icon, use the connection with an "unlocked 
padlock", or drop the connection themselves then.

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/20050314/aad51ffb/signature.bin

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Mon, 14 Mar 2005 11:08:26 -0800

Joe Touch <touch at ISI.EDU> wrote:
> You decide if you want to require BTNS or use it where it's
> available. In the first case, you drop all attempts that don't
> handshake in IKE.
> 
> In the second, you drop packets until IKE succeeds or fails, and
> notify the app (a flag that it would be able to check). Apps that care
> can put up a "locked padlock" icon, use the connection with an
> "unlocked padlock", or drop the connection themselves then.

This seems to have pretty undesirable performance consequences.
I don't think I'd be willing to use the "use if available"
setting if it implies this kind of delay when I connect
to large fractions of the Internet.

-Ekr

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 14 Mar 2005 13:14:20 -0600

> have to reassociate with the new addresses.

It's worse than that -- the mobile client's peers might be running BTNS
too, so now they'll have a persistent {IP address, pubkey} mapping that
prevents re-use of that IP address with BTNS by other clients.

I've been thinking about this and related issues a lot lately.

When I said, at the BoF, that BTNS really needs APIs to be really
useful, I meant it :)  -- w/o APIs we run into such problems as this
one, which, while not fatal, do make BTNS less useful than we might have
hoped for.

> is sufficient to ignore that issue as BTNS-specific.

Yes, but BTNS + APIs + channel bindings do add a lot in this regard.

And opportunistic IPsec + APIs too add a lot.

Pekka was right -- HIP encompasses a lot of functionality that we're
seeking piecemeal and elsewhere in the IETF.  OTOH, it may be that the
only way to reach HIP deployment is piecemeal.

A holistic view of the problem should include APIs to IPsec, key
distribution by PKI, through DNSSEC, and unauthenticated key
distribution (as in BTNS), the last one being particularly useful for
those interested in channel bindings to IPsec.

> In the first case, you drop all attempts that don't handshake in IKE.

Yup.

> the app (a flag that it would be able to check).

Please expand on this.  What do you mean by "flag?"  Existing error
codes in existing APIs?  Or new APIs?

>                                                  Apps that care can put 

Well, this implies APIs.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 14 Mar 2005 13:19:00 -0600

> to large fractions of the Internet.

Hopefully all peers send port unreachable ICMPs if IKE is not running;
that should help.

Opportunistic IPsec, HIP, involve doing additional DNS[SEC] lookups too.
Those will slow you down also...

I'm not sure that BTNS w/ BITS (i.e., w/o APIs) will be useful in the
open Internet, particularly for mobile users, though it will be useful
in Joe's intended scenario (i.e., between routers).

Nico
--

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Mon, 14 Mar 2005 11:36:20 -0800

> Hopefully all peers send port unreachable ICMPs if IKE is not running;

Well, my machines blackhole all forbidden UDP traffic. I imagine
this is a fairly common firewall config.

> Those will slow you down also...

Yes, but they're just normal success or failure things, not reliant
on timeouts. We're potentially talking 30-120 seconds here...

-Ekr

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 11:52:29 -0800

> to large fractions of the Internet.

You use things like that now when you go to some web pages.

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/20050314/473035e0/signature-0001.bin

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Mon, 14 Mar 2005 12:09:22 -0800

> You use things like that now when you go to some web pages.

How's that? If I have a URL in hand, there's a reasonable
expectation that I can make a TCP connection to that 
host/port pair immediately, within the characteristics of
the network. I certainly don't expect to wait a minute
for the initial connection.

-Ekr

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 15:16:26 -0800

> for the initial connection.

It's not a minute, but it is a few different handshakes. It happens all 
the time - IPv4 vs. IPv6, http vs. https, etc. Some apps do implement 
this 'try if available, and if not try the other'.

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/20050314/4d774dc0/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 15:21:14 -0800

...
> one, which, while not fatal, do make BTNS less useful than we might have

Dealing with mobility might be something we discuss later; let's get the 
non-mobile case working first.

If we spend too much time worrying about "making BTNS less useful than 
it might be" we defeat the purpose- 'better than nothing'. 'As useful as 
it might be' is the enemy of 'good enough'.

> those interested in channel bindings to IPsec.

BTNS is a specific solution; the holistic view can be discussed 
elswhere, IMO.

> codes in existing APIs?  Or new APIs?

Error codes in existing APIs if at all possible.

>>padlock", or drop the connection themselves then.

See above.
-------------- 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/20050314/fc760d4b/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 15:26:48 -0800

> 	until an SA arrives (which may never happen).

I don't understand this. Once you send cleartext, you're compromised, 
and you can't trust that subsequent communication is in the secure 
context alone.

> 	initiate in the clear/never initiate any connection (pure server).

There are variants of whether to require it for all incoming or 
outgoing. That seems like SPD configuration more than something we need 
to address by mechanism, though.

> 	- ipseckey or equivalent in DNS

Initial leap-of-faith is how I think of BTNS working. Use of the DNS for 
keying is a non-starter here - that's just moving the infrastructure; 
BTNS is about avoiding infrastructure, not moving it.

>  - "allow BTNS" and "require BTNS" modes can be made compatible.

Compatible with each other? They are - they'd use BTNS. Or did you mean 
something else?

> keep our scope manageable.

Definitely!

(IMO)

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/20050314/3948cb96/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 15:30:36 -0800

> Those will slow you down also...

Not if I don't use them ;-)

It's not "IKE w/CA or key, IKE via DNS key, BTNS, then cleartext", IMO. 
BTNS is appropriate only where you don't care about out-of-band 
identity. If you do, use CAs or shared keys (preshared or 
DNS-distributed). You'd only use BTNS where you don't.

If you don't care about out-of-band identity, then you MIGHT allow 
cleartext, though. I can see the BTNS then cleartext variant being 
useful, e.g., for a webserver (which could throttle non-BTNS connections 
if under heavy load, to avoid potential attackers).

> in Joe's intended scenario (i.e., between routers).

IMO, BTNS w/o APIs will be very useful. I don't see many mobile users 
now, and I do see many web users.

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/20050314/48f26278/signature.bin

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Mon, 14 Mar 2005 16:03:53 -0800

Joe Touch <touch at ISI.EDU> wrote:
> It's not a minute, but it is a few different handshakes. It happens
> all the time - IPv4 vs. IPv6, http vs. https, etc. Some apps do
> implement this 'try if available, and if not try the other'.

Well, I don't even have an IPv6 address, so I'd be pretty
surprised if my apps attempted IPv6 before IPv4. And if
turning on IPv6 created this behavior, I would most
certainly immediately turn it back off again.

As for HTTPS, browsers are guided by the protocol in the URL.
They don't fall back to HTTP if HTTPS fails. They just throw an
error. They also don't try HTTPS before HTTP if provided with an
HTTP URL.

-Ekr

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Mon, 14 Mar 2005 16:05:24 -0800

Joe Touch <touch at ISI.EDU> wrote:
> useful, e.g., for a webserver (which could throttle non-BTNS
> connections if under heavy load, to avoid potential attackers).

I would think more importantly for clients.... However, I don't
see how that can work if it creates an enormous performance hit.

-Ekr

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 14 Mar 2005 20:40:10 -0600

> non-mobile case working first.

Of course.  We must, though, understand why a BITS BTNS host might or
might not work well as a mobile peer or with mobile BTNS peers.

> it might be' is the enemy of 'good enough'.

Who said anything about limiting BTNS' usefulness?  As to making it more
useful, I do seem to recall some charter items at Monday's meeting that
did just that.

I do believe we should and will specify something that works with fairly
naive IPsec implementations (e.g., BITS types).

But remember, we do need to look at channels too, so those of us
interested in channel bindings have channels to bind to.

And realize that without native IPsec / IPsec APIs or IPsec channels
BTNS will be of limited usefulness, whether you like that or not.  My
I-D will explain why; for the time being I'd rather work on the I-D than
debate these matters.

[...]
> BTNS is a specific solution; the holistic view can be discussed 

It is being discussed elsewhere now.  I'm not trying to enlarge this
putative WG's scope, but we must consider BTNS in the context of other
goings on at the IETF -- we ought not work in a vaccuum.

> Error codes in existing APIs if at all possible.

'K.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 14 Mar 2005 20:48:27 -0600

> Not if I don't use them ;-)

:)

> It's not "IKE w/CA or key, IKE via DNS key, BTNS, then cleartext", IMO. 

But that could be a reasonable configuration.

> DNS-distributed). You'd only use BTNS where you don't.

We decided, one week ago, that BTNS and normal IPsec should be able to
co-exist on the same host, and concurrently.

That means that it must be possible to care about using PKI, PSK, keys
in DNS[SEC], for some peers and unauthenticated public keys (BTNS) for
others; that does not mean that one needs a fallback-type policy for
IKE though, but such policies may yet be desirable.

> now, and I do see many web users.

It will be useful for the cases you care about, not for the ones I care
about.  We can deal with both by first addressing the simple BTNS case
(the one that is useful to your use cases) and then, possibly
separately, specifying what else is needed to make it useful in other
use cases.

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 22:07:05 -0800

...
> But that could be a reasonable configuration.

Can you show an example?

Why would I try to identify the endpoint, but if I can't then accept 
non-identified?

> IKE though, but such policies may yet be desirable.

Why is having different policies for different endpoints relevant to 
having fallbacks?

BTNS isn't a variant of IPsec that's exclusive IMO. It's a flag on an 
SPD, or at least that's how I think of it.

Once you set the flag, you're saying "out-of-band identity doesn't 
matter" - so why are you bothering with checking SAs at that point?

> separately, specifying what else is needed to make it useful in other

Definitely. What I hope we can do is figure out how to do BTNS as a mode 
of an IPsec SPD, then elaborate on it as we go.

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/20050314/b15a9fea/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 22:08:00 -0800

> see how that can work if it creates an enormous performance hit.

The 'heavy load' referred to would be from a perceived attack, not a 
performance hit.

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/20050314/d6cd8f97/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 14 Mar 2005 22:09:12 -0800

> certainly immediately turn it back off again.

If you use DNS, it's entirely possible that the app is checking v6 then 
v4, in that order, or in parallel. This issue was discussed in DC in TCPM.

> error. They also don't try HTTPS before HTTP if provided with an

Redirection is how the app is guided into switching or falling back on 
protocols.

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/20050314/29f2b0a1/signature.bin

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Mon, 14 Mar 2005 22:27:26 -0800

Joe Touch <touch at ISI.EDU> wrote:
> If you use DNS, it's entirely possible that the app is checking v6
> then v4, in that order, or in parallel. This issue was discussed in DC
> in TCPM.

Checking DNS in parallel isn't the same as trying to connect to
a host which may be blocking your packets. DNS gives results 
(or a NXDOMAIN) in a semi-deterministic time frame. You don't
have to wait for some timeout on v6 to try v4--at least not if
things are configured correctly.

> Redirection is how the app is guided into switching or falling back on

Once again, redirection is semi-deterministic. You don't end up
just waiting for 30-120 seconds because you tried HTTPS and the
server doesn't support it.

-Ekr

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Mon, 14 Mar 2005 22:29:12 -0800

> The 'heavy load' referred to would be from a perceived attack, not a

Yes, I appreciate that. My point is that I don't believe that clients
(or servers) will implement it if with high probability it results in
very high communications latency.

-Ekr

---

From: kivinen at iki.fi (Tero Kivinen)
Date: Tue, 15 Mar 2005 10:25:56 +0200

> stuck waiting for the timeout. This really delays the initiation of the

Other opportunustic etc encryption schemes have also acted upon ICMP
port unreachables etc, i.e. we could hold packets until we get first
packet back from the other end, if it is ICMP port etc unreachable
then allow traffic in plain, but continue trying IKE connection until
it times out (i.e. if this was faked ICMP packet we will notice it
when the real IKE server responds, and we can then move back to using
IPsec).

If the first packet is IKE packet then we hold the traffic packets
until the exchange is finished (succeeded, or timed out).

In case the port is silently firewalled off, then user will wait for
the (perhaps much shorter than normally) timeout, and then start
sending packets in plain.

Hopefully users then complain to the adminstrator that they are
silently discarding the IKE packets so that adminstrator can fix their
setup to send ICMPs which will make future connections failing faster.

Of course we can also remember from the past connections if the other
host talks IPsec, and adjust the timeouts accordingly (i.e. if it
talked IPsec last time wait for full timeout, if it we timed out last
time, use shorter timeouts etc).

That will help if btns is used between same parties.
-- 
kivinen at safenet-inc.com

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 15 Mar 2005 06:44:02 -0800

Overall, I see this whole issue of how to handle alternatives 
distracting and unnecessary.

IMO, the primary utility of BTNS will be to enable it and require it for 
a set of addresses - via an SPD with a 'use BTNS' flag. I don't think 
IPsec needs to handle BTNS-flagged SPDs differently from other SPDs, nor 
do I think there is any new concern about security that doing this 
raises - notably, because the SPD could have said "pass", which is less 
secure than BTNS, and IPsec already needs to keep those streams separate.

IPsec doesn't (AFAIK) have a "please key, but if you timeout, that's OK 
so just 'pass' traffic" mode; I don't see that as being uniquely useful 
to BTNS or requiring discussion at this point.

Joe

Eric Rescorla wrote:
> _______________________________________________
-------------- 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/20050315/01f0a57b/signature.bin

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Tue, 15 Mar 2005 07:14:22 -0800

> distracting and unnecessary.

Obviously, I disagree.

> IMO, the primary utility of BTNS will be to enable it and require it
> for a set of addresses - via an SPD with a 'use BTNS' flag. I don't
> think IPsec needs to handle BTNS-flagged SPDs differently from other
> SPDs, nor do I think there is any new concern about security that
> doing this raises - notably, because the SPD could have said "pass",
> which is less secure than BTNS, and IPsec already needs to keep those
> streams separate.
> 
> IPsec doesn't (AFAIK) have a "please key, but if you timeout, that's
> OK so just 'pass' traffic" mode; I don't see that as being uniquely
> useful to BTNS or requiring discussion at this point.

It's not a security concern, it's a performance and deployment
concern. 

Let's talk big picture for a second. There are (at least) two ways
that BTNS can be used:

1. Use BTNS or nothing.
2. Use BTNS or fall back to cleartext.

Now, in case (1), you definitely can't turn on BTNS unless you
absolutely know that the peer does BTNS, because otherwise you
can't communicate. This means that you need to have a prior
arrangement with the peer, at which point they could easily
have provided a public key fingerprint, at which point you
could do more or less standard IKE (replacing the cert check
with a comparison to the fingerprint, which is easy to add
and not really a wire protocol issue) and call it a day.

So, I think BTNS mostly makes sense with a fallback to plaintext.
But then what you want is for people to turn it on globally
for all possible peers. This isn't going to work if people
have to take a big performance hit for doing so.

Do you have some different usage model where this makes sense?

-Ekr

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 15 Mar 2005 07:33:00 -0800

> and not really a wire protocol issue) and call it a day.

Consider the following:

- give people two different URLs - one that triggers BTNS, one that does 
not (e.g., two different IP addresses)

- let users pick, but give preferential treatment under heavy load to 
the BTNS address, because it is more protected from attack

As to key distribution, the assertion that if I have BTNS then you and I 
have a key isn't true; many systems already have IPsec, but lack the 
key. That's the whole point of BTNS - to avoid needing per-pair 
prearrangement.

If backoff is really required, we can try IKE with a new option; the 
option should be immediately declined as not supported, and this should 
not require a timeout. Timeout would occur only if the other end didn't 
even have IKE; that's no different from today. Fix that with IKE first, 
then let me know how BTNS is different. ;-)

BTNS does not solve the "I don't even speak IKE" stuff; it solves the "I 
speak IKE, but don't have a preshared secret (key or pre-agreed CA).".

> So, I think BTNS mostly makes sense with a fallback to plaintext.

Fallback to plaintext != fallback to non-IPsec. That may indeed be 
useful, but can't be done without timeouts as you mention. BTNS doesn't 
solve the non-IPsec case, again.

-------------- 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/20050315/ec192478/signature-0001.bin

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Tue, 15 Mar 2005 08:03:48 -0800

Joe Touch <touch at ISI.EDU> wrote:
> > concern. Let's talk big picture for a second. There are (at least)
> > two ways
> > that BTNS can be used:
> > 1. Use BTNS or nothing.
> - give people two different URLs - one that triggers BTNS, one that
> does not (e.g., two different IP addresses)

This is basically manual backoff. I don't really believe that
people will do this.

> the BTNS address, because it is more protected from attack

I hear this kind of proposal for preferential network load 
handling a lot, but I'm skeptical of its value. Modern DDoS 
attacks tend to be of the lots of packets variety. And since
it's easy for an attacker to do BTNS anyway...

> As to key distribution, the assertion that if I have BTNS then you and
> I have a key isn't true; many systems already have IPsec, but lack the

What I said was if I *knew* you had BTNS then we can arrange a 
fingerprint through the same channel through which I learned you
had BTNS.

> option should be immediately declined as not supported, and this
> should not require a timeout. Timeout would occur only if the other
> end didn't even have IKE; that's no different from today. Fix that
> with IKE first, then let me know how BTNS is different. ;-)

The situations aren't the same, because with IKE now you never
want to fallback to non-IPsec. However, with BTNS, you might want
to and that's how the problem arises.

> BTNS does not solve the "I don't even speak IKE" stuff; it solves the
> "I speak IKE, but don't have a preshared secret (key or pre-agreed
> CA).".
> 
> useful, but can't be done without timeouts as you mention. BTNS
> doesn't solve the non-IPsec case, again.

Hmm.... I'd imagined it was intended to. If it doesn't, it strikes
me as far less useful.

-Ekr

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Tue, 15 Mar 2005 08:17:11 -0800

> fingerprint through the same channel through which I learned you

To be specific, what I meant was that whatever tool you use
to set the new SPD entry can easily fetch the peer's certificate
and write a digest to the SPD, thus removing the need for
modifications to IPsec.

-Ekr

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 15 Mar 2005 08:21:07 -0800

> and write a digest to the SPD, thus removing the need for

How do you fetch the certificate for the SPD 10.*.*.* ?

Besides, even if it were for a single address, why fetch a certificate 
you don't care to check? (again, that misses the point of BTNS).

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/20050315/c836839b/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 15 Mar 2005 08:32:49 -0800

...
> This is basically manual backoff. I don't really believe that

Beliefs about what people will or will not do got us here - with forced 
keys, whether preshared, the shared CA, or shared in a database (e.g. DNS).

Let's try this as a different path, and find out what people really do 
rather than speculating again. ;-)

> it's easy for an attacker to do BTNS anyway...

Again, this misses the point of BTNS. Anybody who does enough work to 
setup an association is indistinguishable from a legitimate user, and 
deserves to be treated as such.

There is a lot of work throughout the IETF aimed at dealing with modern 
DDOS attacks that attack specific connections, not just flooding the 
whole net with packets. We saw this with TCP SYN attacks, we see it with 
RST attacks, etc. This is not conjecture.

The 'lots of packets' attack needs to be vetted somehow anyway - IPsec 
is supposed to handle those too, and if it doesn't, there's little hope 
of any alternative handling it better.

> fingerprint through the same channel through which I learned you

What makes you think you
	a) know I have BTNS?

		by the time you do, we should already be knee-deep
		in DH exchange, IMO

	b) should bother with an exchange whose result
	   shouldn't be relevant?

		if you start to talk with an endpoint that early,
		why not proactively setup the SA, rather than
		getting CAs you are going to ignore?

> want to fallback to non-IPsec.

Not necessarily; you could want to lock things down where you can but 
still provide open access to less detailed info where you can't.

> However, with BTNS, you might want

As above, I don't agree that it arises here. First, there's sufficient 
(IMO primary) utility in the non-backoff case. Second, the backoff case 
is no different from IPsec backoff to cleartext. There's nothing 
BTNS-specific about this.

> Hmm.... I'd imagined it was intended to. If it doesn't, it strikes

Not me. BTNS isn't a replacement for IPsec; it's a replacement for 
needing preshared keys or CAs in IPsec (as well as the correlary need in 
other protocols, eventually, but that's my overall vision, not this WG).

The problem of fallback on systems that lack any pre-deployed protocol 
to explicitly negotiate security is one of telepathy. Timeouts are the 
only solution, and have known problems. If you solve that problem, let 
us know, but otherwise I think it's out of scope because it's not 
remotely new.

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/20050315/703a0a1d/signature.bin

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Tue, 15 Mar 2005 08:40:41 -0800

> you don't care to check? (again, that misses the point of BTNS).

Because I'm trying to figure out how to do this without writing
new RFCs, of course?

-Ekr

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Tue, 15 Mar 2005 08:50:10 -0800

Joe Touch <touch at ISI.EDU> wrote:
> > I hear this kind of proposal for preferential network load handling
> > a lot, but I'm skeptical of its value. Modern DDoS attacks tend to
> > be of the lots of packets variety. And since

This basically buys you zilch aainst zombies, which are the current
major threeat.

> There is a lot of work throughout the IETF aimed at dealing with
> modern DDOS attacks that attack specific connections, not just
> flooding the whole net with packets. We saw this with TCP SYN attacks,
> we see it with RST attacks, etc. This is not conjecture.

Actually, the data suggests that modern attacks are lots of packets
attacks, NOT targeted clever TCP-based stuff. See

http://www.monkey.org/~jose/presentations/ddos.d/

> 		by the time you do, we should already be knee-deep

Sorry, I should have said "know you have IKE". Once again,
the concern is waiting for a connction to someone who ahs
no IKE capability.

> us know, but otherwise I think it's out of scope because it's not

Well, the question at hand is whether BTNS is actually useful
if it requires people to time out constantly. The fact that I
don't have a useful solution to the problem doesn't make it
go away.

That said, it seems to me that you've dismissed the "start
transmitting in the clear and then switch over if/when you get
an association" strategy rather too quickly.
   
-Ekr

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 15 Mar 2005 10:53:50 -0600

> don't have a useful solution to the problem doesn't make it

For the use case that Joe cares about (protecting routers against RST
attacks on their BGP TCP connections) BTNS is useful and timeouts won't
be an issue.

> an association" strategy rather too quickly.

In the router case it should be easy enough to get BTNS to just work
that you might not ever care about fallback modes.

More generally you might care about fallbacks, but then you get into the
mobility issues I pointed out before -- as a result BTNS w/ BITS mode
IPsec is limited, pretty much, to use cases like Joe's.

Nico
--

---

From: Julien.Laganier at Sun.COM (Julien Laganier)
Date: Tue, 15 Mar 2005 18:48:15 +0100

> don't have a useful solution to the problem doesn't make it

This looks similar to me to the experience of an user using remote 
login: One might first try to use SSH, and if it gets an ICMP port 
unreachable, would switch to Telnet, for example. Now if the remote 
box doesn't send such ICMPs, the user will have to Timeout. This has 
happened quite a lot to me.

I don't see how BTNS is different w.r.t to this behavior. If the 
remote box is correctly configured it should send ICMP port btns 
unreachable, so no timeouts. If it's not properly configured, then... 
what can we do better?

> an association" strategy rather too quickly.

An SPD entry in KAME IPsec might have this feature enabled (via the 
'use' flag instead of 'require' flag). The traffic pass in clear 
until an IPsec association is possibly established.

--julien

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 15 Mar 2005 10:58:33 -0800

> Because I'm trying to figure out how to do this without writing

You haven't said why you want to fetch certificates you don't want to check.

If you want to check certificates, that may indeed require new RFCs, but 
that's not BTNS.

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/20050315/f539d27e/signature-0001.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 15 Mar 2005 11:04:30 -0800

> This basically buys you zilch aainst zombies, which are the current

Zombies that do full connections, agreed. That's NOT the threat people 
are discussing throughout the IETF right now, the one that gave rise to 
_this_ BOF/WG.

Note that zombies might even have signed certificates - just that 
they've been compromised. So no defense is valid against them, since 
they are isomorphic to legitimate users.

If you come up with a way to fix that, let us all know. In another WG, 
because that's outside the scope of this WG.

> http://www.monkey.org/~jose/presentations/ddos.d/

If you want to argue that there are other solutions needed, please do so 
in another WG/BOF. Lots-of-packets attacks hit IPsec, BTNS-IPsec, SSH, 
and everything else.

Again, if you come up with a way to fix that, please let us all know - 
in another WG.

> the concern is waiting for a connction to someone who ahs

Again (arrgh), if you come up with a way to solve avoiding a timeout for 
IKE vs. non-IKE, let us know (in another WG). That's outside the scope 
of BTNS, and has nothing to do with BTNS.

> if it requires people to time out constantly.

You're still assuming that it's not useful unless there's a fallback to 
cleartext; I am not.

> The fact that I

It also doesn't make it a problem for this WG ;-)

> an association" strategy rather too quickly.

Too quickly for you, but not too quickly for me. I don't consider that a 
viable alternative at all. If anhyone else does, we can talk about it, 
but I haven't heard a groundswell in favor, nor have I heard a 
convincing argument as to why it's critical to getting BTNS out the door 
or used.

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/20050315/0bc3bd47/signature.bin

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Tue, 15 Mar 2005 13:28:22 -0800

Joe Touch <touch at ISI.EDU> wrote:
> are discussing throughout the IETF right now, the one that gave rise
> to _this_ BOF/WG.
> 

Is this even a WG at all yet? I thought the question on the table
was whether the piece of work you propose to do was worth actually
doing, a context in which the issues I'm raising are quite relevant.

> for IKE vs. non-IKE, let us know (in another WG). That's outside the
> scope of BTNS, and has nothing to do with BTNS.

Once again, the fact that BTNS brings up the issue of falling back
to cleartext is what makes this an issue here.

> Too quickly for you, but not too quickly for me. I don't consider that
> a viable alternative at all.

Oh, well than that totally settles it, I guess... 

Do you have an actual argument to make here?

-Ekr

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 15 Mar 2005 13:44:49 -0800

Eric Rescorla wrote:
...
> doing, a context in which the issues I'm raising are quite relevant.

That vote was decided last IETF, and the rest is in the hands of the 
IESG; the question is one of scope so far, and I believe this issue is 
outside of scope. Others can voice their position.

> to cleartext is what makes this an issue here.

I disagree; I don't think BTNS brings up the issue of cleartext fallback 
per se.

> Do you have an actual argument to make here?

I've made it multiple times in more detail; you disagree. We know where 
we both stand; let's hear from others.

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/20050315/da28bf3f/signature.bin

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Tue, 15 Mar 2005 13:58:00 -0800

> outside of scope. Others can voice their position.

Which is what I'm doing...

> I've made it multiple times in more detail; you disagree. We know
> where we both stand; let's hear from others.

Works for me.

-Ekr

---

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue, 15 Mar 2005 14:00:12 -0800

>This basically buys you zilch aainst zombies, which are the current

Are you suggesting that prevention of attack by zombies be put in the 
charter? If so, why should that be in BTNS' charter but no one else's?

>the concern is waiting for a connction to someone who ahs

This line of argument is quite similar to the "foo-over-SSL on a 
different port vs. SSL upgrade such as STARTTLS". The result is quite 
similar: if the initiator has a policy to try BTNS, they need to have 
a fallback if IKE fails to give them what they want, and another 
policy if IKE doesn't even start up in a reasonable time.

>if it requires people to time out constantly.

Nothing said so far "requires people to time out constantly". BTNS is 
an optional service. It would be reasonable of an implementer to put 
something in their code that says "if I timed out the last time I 
tried to get security with BTNS, don't try this time". It would be 
even smarter to retry BTNS at other times to see if there is now a 
working BTNS service.

>an association" strategy rather too quickly.

Agree. This option could be discussed in the protocol document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 15 Mar 2005 16:05:35 -0600

> Agree. This option could be discussed in the protocol document.

Emphasis on "optional."

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Tue, 15 Mar 2005 17:16:10 -0500

> we both stand; let's hear from others.

As an implementor I can do things either way.  Joe's approach is
slightly
easier.

What Joe asks for could be done via a per-socket bit, either from the
SPD 
or from the application saying (via a socket option or moral equivalent)
that BTNS was requested/required.

A "this is for BTNS" vs "this requires conventional IKE authentication" 
bit could be reflected to key management via a new PF_KEY extension.

The existence of SPD/PAD entries calling for conventional IPsec/IKE 
authentication would, of course, trump/subsume this application request.

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue, 15 Mar 2005 16:20:28 -0600

> authentication would, of course, trump/subsume this application request.

What Bill said.

Note that Bill mentions APIs... :)

Nico
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 23 Mar 2005 23:11:23 -0500

>>>>> "Eric" == Eric Rescorla <ekr at rtfm.com> writes:

    Eric> Joe Touch <touch at ISI.EDU> wrote:
    >> In the second, you drop packets until IKE succeeds or fails,
    >> and notify the app (a flag that it would be able to
    >> check). Apps that care can put up a "locked padlock" icon, use
    >> the connection with an "unlocked padlock", or drop the
    >> connection themselves then.

    Eric> This seems to have pretty undesirable performance
    Eric> consequences.  I don't think I'd be willing to use the "use
    Eric> if available" setting if it implies this kind of delay when
    Eric> I connect to large fractions of the Internet.

Today, I certainly would not want it to be the default.  I might well
decide I want it as a default for some protocols though.  It seems
like a reasonable option to support if it doesn't get in the way too
much.

---

From: ekr at rtfm.com (Eric Rescorla)
Date: Wed, 23 Mar 2005 20:27:04 -0800

> like a reasonable option to support if it doesn't get in the way too

OK...

I think the key question here is whether we should standardize
a protocol that provides *only* this option.

-Ekr

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Wed, 23 Mar 2005 23:50:59 -0500

Eric> Eric Rescorla <ekr at rtfm.com> wrote:
    >> > As to key distribution, the assertion that if I have BTNS
    >> then you and > I have a key isn't true; many systems already
    >> have IPsec, but lack the > key. That's the whole point of BTNS
    >> - to avoid needing per-pair > prearrangement.
    >> 
    >> fingerprint through the same channel through which I learned
    >> you had BTNS.

    Eric> To be specific, what I meant was that whatever tool you use
    Eric> to set the new SPD entry can easily fetch the peer's
    Eric> certificate and write a digest to the SPD, thus removing the
    Eric> need for modifications to IPsec.

It has been my experience that saying "mandate security" requires less of
a channel than "mandate security; my public key hash is deadbeeffacebad"

Reasons you might not be able to retrieve certificates:

* Applying "mandate security" to a large number of destinations

* Some destinations (or you) are offline when you make the policy assertion

* The lifetime of the "mandate security" policy assertion is longer
  than the lifetime of the certs 

Note that we may not need any IKE modifications.  The charter
anticipates this possibility.  Personally I think we'll need some
normative text that lets you say "self signed certs OK" as I expect
the output of PKI4IPSEC will probably mandate that you do cert path
validation and other things we do not want to do.  Even so, you're
going to need PAD/SPD changes.

It's clear to me there are RFCs to be written even if there are not
IKEs to be modified.