Subject: [anonsec] what kind of phase 2 SAs are we negotiating?

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Fri, 08 Apr 2005 12:40:55 -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/d1634c94/attachment.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 8 Apr 2005 12:35:00 -0500

On Fri, Apr 08, 2005 at 12:40:55PM -0400, Michael Richardson wrote:
> 
> Here is a question that I wish to pose:
>      what kind of phase 2 things are we negotiating?
> 
> Fundamentally, this is a question about tunnel vs transport mode, but
>                there are now significant additional items to concern oneself
>                about.

IMO, transport only.

> Given two full-citizen (non-NAT'ed, globally routable, globally unique) nodes
> on the internet, they could negotiate anything they wish.  They can offer a
> multitude of possibilities up to 64K UDP packet size for IKE. 
> That's not what concerns me.
> 
> What I want to know is if an initiator node using NAT-Traversal is allowed to
> participate.  (double-NAT out of scope for this message)

NAT-T brings into the matter the same issues as mobility and credential
changes.  Namely, BTNS, in BITS-mode implementations anyways, will have
to rely on making new PAD entries in a leap-of-faith manner, but these
PAD entries have to persist and be unique (one PAD entry per-peer IP
address), which clearly conflicts with NAT-T and mobility scenarios in
which multiple peers can share a single address either concurrently or
sequentially.

Therefore, BTNS, in BITS-mode implementations anyways, will be useful
only in scenarios where you know a priori which peer addresses will be
used with BTNS -- i.e., the usefulness of this is rather limited; it's
just enough to cover Joe's primary use case.

Now, I can see BTNS as working somewhat (Ok, significantly) differently
in native mode IPsec implementations, where we can involve the transport
protocols (and applications) in policy matters.

When I stated, at the last BoF, that BTNS would not be very useful
without APIs, what I meant is that for BTNS to be really useful we need
native IPsec...

...that with native IPsec, and the interfaces between IPsec and
transport and application layers that that (in my mind) implies, we can
express temporary, rather than persistent, peer/public key bindings on a
per-connection or per-datagram basis, with application knowledge of
peers' BTNS credentials (raw public keys), such that responsibility for
authorization is moved from l3 to l7.  (Channel bindings then simplify
matters for applications.)

Cheers,

Nico
--

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Fri, 08 Apr 2005 14:40:45 -0400

>>>>> "Michael" == Michael Richardson <mcr at sandelman.ottawa.on.ca> writes:

    Michael> Here is a question that I wish to pose: what kind of
    Michael> phase 2 things are we negotiating?

    Michael> Fundamentally, this is a question about tunnel vs
    Michael> transport mode, but there are now significant additional
    Michael> items to concern oneself about.

In general I'd expect transport mode SAs to be used.  There was
discussion on the list earlier suggesting that transport or tunnel was
OK provided it was end-to-end.  I.E. you should not use BTNS to
"securely" route a network.

I'm OK if that's what we decide.  However I'd encourage people to read
draft-ietf-l3vpn-ipsec-2547 and draft-ietf-l3vpn-gre-2547.  These
drafts are best not read on a full stomach and should perhaps not be
read with sharp objects near by.

Briefly the l3vpn people want a way of tunneling a certain kind of
MPLS VPN over IP.  I'm blocking draft-ietf-l3vpn-gre-2547 because
there's no security solution at all and because
draft-ietf-l3vpn-ipsec-2547 makes it clear that static configuration
is not appropriate.

The security goals are fairly limited: it needs to be as secure as
existing MPLS.  I.E. an off-path attacker should not be able to inject
packets.

It may well be that BTNS tunnels is the best solution we can come up
with for the L3VPN folks.  They seem to think configuring a full IKE
infrastructure is too much work.

Just some food for thought,

--Sam

---

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

>>               there are now significant additional items to concern oneself

I don't see how it matters. Yes, there are security implications to
setting up tunnels with BTNS, but ditto for tunnels with improperly
secured passwords. I don't think the technology ought to set policy;
that's for the user to determine.

Joe

---

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

> "securely" route a network.

Agreed. But that's not something, IMO, that the technology can enforce
(vs. using tunnels to the endpoint for whatever reason). While we can
avoid that by forcing tunnel mode to be forbidden for BTNS, users can
always tunnel over transport mode anyway, so there's no real point to
pushing the recommendation into the specification, IMO.

Yes, the applicability statement should address this, but, IMO, not the
solution.

Joe

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Fri, 08 Apr 2005 14:58:27 -0400

>>>>> "Joe" == Joe Touch <touch at ISI.EDU> writes:

    Joe> I don't see how it matters. Yes, there are security
    Joe> implications to setting up tunnels with BTNS, but ditto for
    Joe> tunnels with improperly secured passwords. I don't think the
    Joe> technology ought to set policy; that's for the user to
    Joe> determine.

One of the things we signed up to deliver is an applicability
statement to help users figure out when BTNS is an appropriate
technology.  So, yes, it is our job to set policy at that level.

Similarly it is our job to give the IETF advice on when BTNS is the
right technology to use.  It would be reasonable for us to have
explicit rules or general advice.

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Fri, 08 Apr 2005 15:42:14 -0400

> pushing the recommendation into the specification, IMO.

Actually, there is, and it comes down to the difference between
"tunneling in transport mode" (by mutual consent) and true tunnel mode.

If the tunnel inside address != the tunnel outside address, a malicious
initiator could potentially subvert routing and steal traffic.

i.e., i initiate from whatever address I'm at and say my inner selectors
are 198.41.0.4; if the peer's policy accepts those selectors, the peer
may wind up sending traffic for a.root-servers.net to me through the
tunnel.

(On the other hand, if the inner addresses are configured on each end --
with the tunnel just being an application running over BTNS/ipsec then
BTNS would be a fine way to set up an encrypted tunnel by mutual
consent.)

to avoid traffic-vacuuming attacks we're going to need to tightly
constrain the selectors for tunnel mode if we allow tunnel mode at all. 
for btns use we presumably want to limit the src and dst addresses such
that the inner and outer addresses are the same, so the capabilities are
pretty much the same as transport mode with the exception that the
packets are bigger..

							- Bill

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 08 Apr 2005 13:39:33 -0700

> "tunneling in transport mode" (by mutual consent) and true tunnel mode.

This is only because transport mode isn't - it applies only to certain
payload (transport) protocols (TCP, SCTP, UDP); if it were truly
'transport', it would accomodate any IP payload (transport) protocol and
verify contents as needed. IP inside IP isn't properly checked, so yes,
this is different, but also known.

But that has nothing to do with telling people not to use tunnel mode
with BTNS; it might in fact force them to use tunnels over transport
where that's not what they wanted to do.

> BTNS would be a fine way to set up an encrypted tunnel by mutual

You just said this wasn't any good because addresses outside the tunnel
could leak in (which is true), or at least that IPsec wouldn't validate
them. So no, mutual consent is insufficient. You need additional checks
of the inner address to be equivalent.

> constrain the selectors for tunnel mode if we allow tunnel mode at all. 

Not any more than any other tunnel-mode use needs to, IMO. I.e., there's
no difference between using BTNS vs. using a key with a different level
of trust; in both cases, the streams can cross. That sort of policy
management framework doesn't exist elsewhere in the IPsec framework, and
I don't see why this is a new version that needs more attention.

> pretty much the same as transport mode with the exception that the

BTNS could still be useful (or as useful as anything else, IMO) for
tunnels that had separately negotiated addresses; the key issue is that
the addresses are checked. So that would mean tunnel mode with [*,*]
addresses might be considered dangerous, but they are already anyway, IMO.

Joe

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Sat, 09 Apr 2005 11:39: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/c9153cfe/attachment.bin

---

From: kent at bbn.com (Stephen Kent)
Date: Mon, 11 Apr 2005 12:22:37 -0400

At 1:39 PM -0700 4/8/05, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Bill Sommerfeld wrote:

The term "transport" was chosen explicitly to indicate that it was 
designed to carry transport layer protocols of the sort cited above. 
The term is appropriate and evocative.

Steve

---

From: mcr at sandelman.ottawa.on.ca (Michael Richardson)
Date: Thu, 28 Apr 2005 09:31:46 -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/0c926c9b/attachment.bin