Subject: [anonsec] Automatic detection of BTNS capability

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Fri, 08 Apr 2005 11:46:24 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20050408/79128073/attachment.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 08 Apr 2005 11:49:26 -0700

Michael Richardson wrote:
>>>>>>"Bill" == Bill Sommerfeld <sommerfeld at sun.com> writes:
> 
>     Bill> On Mon, 2005-03-14 at 11:12, Eric Rescorla wrote:
>     >> 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...
> 
>     Bill> yes, though I believe the some of the opportunistic IPsec folk may
>     Bill> already have running code for the latter model.
> 
>   No, our version of OE does not do IKE in parallel with traffic.
> 
>   We thought about that a lot, but decided not to do that for complexity
> reasons.  
> 
>   My opinion:
>      a) either BTNS is configured on a per-IP/per-block basis,
>         with 0.0.0.0/0 being an option.
> 
>      b) ability to do BTNS is communicated in-band to another protocol.
>         I.e. via TCP option or IP option.

Or IKE.

...
>   (b) is potentially architecturally cleaner.

Agreed.

Yes, there are problems with IKE and firewalls, NATs, etc. But layering
IKE on top of other protocols (e.g., DNS ;-) just to get around filters
seems unproductive.

Joe

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sat, 09 Apr 2005 11:44:31 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20050409/7d981017/attachment.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon, 11 Apr 2005 10:16:06 -0500

On Sat, Apr 09, 2005 at 11:44:31AM -0400, Michael Richardson wrote:
> 
> >>>>> "Joe" == Joe Touch <touch at ISI.EDU> writes:
>     Joe> Or IKE.
>   That was option (a). You just try IKE.
> 
>   The point is, if the IKE port is blocked (perhaps by an attacker!) you have
> an effective bid-down attack.  We need a way for the end points to say, "I
> could have done BTNS".

But you need a way to get the "I could have done BTNS" message across
with integrity protection.  If you're not doing that at the IPsec layer,
you kinda have to do it at the application layer.  Since the attacker is
active, in this scenario, you need a way to authenticate the peers
(which BTNS doesn't provide).  Except in the case where you would have
used channel bindings in an application that can do authentication at
the app layer, you can't protect the message, and the best you can do
then is to trade off between DoS and downgrade attacks.

>     Joe> Agreed.
>     Joe> Yes, there are problems with IKE and firewalls, NATs, etc. But
>     Joe> layering IKE on top of other protocols (e.g., DNS ;-) just to get
>     Joe> around filters seems unproductive.
> 
>   I think you think I suggested running IKE in port 53 or something.
>   Is that what you think I said?

Hmmm.  Or port 80 ;)

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 11 Apr 2005 09:26:55 -0700

> an effective bid-down attack.  We need a way for the end points to say, "I

If IKE is blocked, I can reinvent IKE on a non-blocked port, but
otherwise all I'm doing is fighting a port block. That's not what
security protocols are designed to address.

>   Is that what you think I said?

That's what OE does (IMO, effectively) by using DNS messages. ;-)

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/20050411/5fff3cb6/signature.bin

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Thu, 28 Apr 2005 09:43:29 -0400

A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 306 bytes
Desc: not available
Url : http://www.postel.org/pipermail/anonsec/attachments/20050428/12ba8f12/attachment.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 28 Apr 2005 07:54:10 -0700

Michael Richardson wrote:
>     >> The point is, if the IKE port is blocked (perhaps by an attacker!) you
>     >> have an effective bid-down attack.  We need a way for the end points
>     >> to say, "I could have done BTNS".
> 
>     Joe> If IKE is blocked, I can reinvent IKE on a non-blocked port, but
>     Joe> otherwise all I'm doing is fighting a port block. That's not what
>     Joe> security protocols are designed to address.
> 
>   Yes, but in the VPN situation, one knows a-priori that there should be a
> VPN, and one can respond to a port-blocked by not transmitting sensitive
> traffic. 

IMO, that should be done anyway.

>   I think, btw, we should proceed with "just try IKE".
>   Like OE, I think we to describe an abstracted concecptual model that one
> can have different classes of traffic (implementable in current SPD). 

Can you explain this further?

>   We may want to describe a way of caching both positive and negative
> discoveries about the peer (including ssh-type leap-of-faith).

That seems like a useful extension to IKE but orthogonal to BTNS. I.e.,
all IKE conversatins benefit from such caching, don't they? If so, that
seems like it could be factored out...

>   I would like to have us describe TCP and SCTP options that say "I could
> have done BTNS", which may optionally be sent. We may also want to describe
> similiar options for protocols that are important to us (BGP, SMTP) that
> could say the same thing. In many cases, these notifications could certainly
> be removed by an attacker --- but we are no worse than before, and the
> notifications may serve to remove non-malicious blocks.

These seem like 'channel binding options' - though I don't know in what
protocol they might appear, they are part of the transport or
application protocol knowing that security is happening at other layers,
right? If so, that'd be part of the channel bindings doc(s), right?

>     >> I think you think I suggested running IKE in port 53 or something.  Is
>     >> that what you think I said?
> 
>     Joe> That's what OE does (IMO, effectively) by using DNS messages. ;-)
> 
>   Yes, I agree. 
>   But, I'm asking *you* if that's what you meant: run IKE on port 53. I'm
> trying to understand your above statement.

It was reductio ad absurdum. The point was that protocols for network
management and configuration, which is what I consider IKE and OE, need
to be able to run on well-known ports. The fact that ports are blocked
is NOT a reason to create per-protocol designs to get around that; all
that would mean is that ports cease to be the way we identify
application protocols.

We already know a few ways to hide traffic from one port in another, to
run DNS over HTTP, or HTTP over DNS, etc. If we need to run IKE over
these protocols to get around port blocking, so be it, but that's
orthogonal to _their_ design.

However, I beleive that OE chose to put key info in the DNS partly to
combine IKE-like keying, opportunistic distribution of keys, AND a
mechanism that natively used the DNS port. I don't see us doing that
here; IMO, we ought to extend IKE as little as possible to get what we
want done. If then there are equivalent OE extensions to support BTNS,
that's fine too.

>   The difference between running DNS on port 53 (to get capability
> information) vs running IKE on port 53 is that it uses cacheable, proxy-able,
> NAT'able, well published protocol.

How is DNS NAT'able? What does it mean to ask someone behind a NAT about
an IP address, and how does it get translated? Sure, it's cacheable, and
proxyable, but the DNS isn't NAT'able.

If you don't like 53, pick 446 (HTTPS). The point is more that we
already know how to bury protocols behind non-native ports (and their
limitations) as a separate issue.

>   (No surprises for any net-admins, no queries to machines that aren't
> expected to receive traffic). 
> 
>   The communication is with another node (the DNS server), which may not be
> on the same forwarding path (vulnerable to the same attackers), and for which
> we have a published protocol that explains how to do do integrity protection.

Same for HTTPS, which might be a better example of what I was getting at.

We understand some of the reasons you chose to put the info in the DNS,
but we're starting with IKE, and BTNS isn't about solving the IKE port
blocking problem any more than OE is about solving the DNS port blocking
problem.

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/20050428/0aa4451a/signature.bin