Subject: [anonsec] My thoughts on the how to detect BTNS thread

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

Some thoughts mostly as an individual not as an AD.

* Ekr has convinced me that the start with cleartext and end up with
  BTNS mode was dismissed too quickly.  I think we should seriously
  consider the implications of that mode.

* Leap of faith concerns me greatly.  I'm concerned that we need to
  consider how key rollover works.  Briefly we need to make sure that
  keys are not assumed to last too long and that bindings to
  identifiers (like IP addresses) are not longer than those
  identifiers are actually valid for the peer.  On the other hand leap
  of faith is useful.

* Joe's tendency to decide far-reaching architectural issues are out
  of scope bothers me a lot.  Solving them is almost certainly out of
  scope.  However we always have a duty to understand the
  architectural implications of the work we do.  We should constantly
  evaluate whether one approach will make other broader issues easier
  to deal with in the future.  Similarly when we find an unexpected
  architectural issue we should re-evaluate whether our efforts still
  make sense.  The challenge is to make sure that we do not get lost
  in the big picture and fail to deliver our small part.  We do not
  need to be all things to all people, but we should at least roughly
  know what we are to most people.

General hint for trying to move things out of scope: if having a
discussion will take less effort than convincing people a discussion
is out of scope, sit back and have the discussion.

---

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed, 23 Mar 2005 20:58:09 -0800

>   consider the implications of that mode.

This has been discussed before in what many people say is the first 
serious attempt to do this in the IETF: upgrading an active SMTP to 
SSL mid-conversation. That discussion turned religious fairly 
quickly, but it might not this time. The archives at 
<http://www.imc.org/ietf-apps-tls/> are a good starting point.

--Paul Hoffman, Director
--VPN Consortium

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 23 Mar 2005 22:02:59 -0800

>   consider the implications of that mode.

That mode might have utility, but it has a number of dangers as well. 
More importantly, there is no reason that mode is particular to BTNS; it 
could potentially be applied to any SA.

>   know what we are to most people.

Agreed; however, there is a fine line between considering the 
implications of our work and considering all possible remotely related 
implications. The former is constructive; the latter, distracting. To 
the extent that I feel that some issues raised apply equally well to 
more conventional IPsec use, they are distracting. To ignore those 
distractions bothers me a lot ;-)

> is out of scope, sit back and have the discussion.

Sometimes it is the understanding of *why* things are out of scope that 
is more important than the amount of time we spend either way. We have a 
duty to understand that, IMO, as well ;-)

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/20050323/35f4ac8f/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 23 Mar 2005 22:04:23 -0800

> <http://www.imc.org/ietf-apps-tls/> are a good starting point.

Is there a precis of that discussion? (or would you or anyone else be 
willing to provide one?) I.e., one email-long?

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/20050323/c3c43b07/signature-0001.bin

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 24 Mar 2005 13:47:19 -0600

>   consider the implications of that mode.

As long as that mode is not required I won't object :)

>   identifiers are actually valid for the peer.  On the other hand leap

As I've been pointing out to folks there is definitely such a problem
with leap-of-faith here, though I've focused on the mobility angle.

A BTNS implementation in a BITS[*] IPsec implementation would have to
make a persistent PAD entry for a new peer's public key, which, combined
with not authenticating the peer's key amounts to leap-of-faith
"authentication."

Peer mobility, like key rollover, causes problems then, as there's
currently no way to communicate peer address or credential changes to
the PAD in the BITS IPsec implementation.

Consider mobility: a mobile node comes along and causes a persistent
entry to be created at some peer's PAD, then it goes away and a new node
re-uses the same dynamically assigned address as the previous node, but
the new node now cannot communicate with thold node's peers as its
public key will be different from the previous node's.

Clearly key rollover is similar to peer mobility in this context, and
has similar consequences: manual intervention or additional IKE
extensions will be needed for BITS IPsec w/ BTNS to cope with key
rollover / address changes.

Perhaps this is a problem that the MOBIKE WG can help with.  I note that
its charter does not mention the PAD, though it mentions changing
established SAs' endpoints (it speaks of "SA gateway addresses," which
sounds unfortunately VPN-specfic), but it seems to me that, in a 2401bis
world it ought to.

[*] A BTNS implementation in a native IPsec implementation may not have
    this problem as the applications may effectively control the
    lifetime of the otherwise persistent PAD entries created by BTNS.

    Note that apps need APIs in order to effect such control; implicit
    control through, say, socket APIs, specifically connect() and
    shutdown() is insufficient as an application may need multiple
    connections to a peer, possibly separated in time.

Cheers,

Nico
--