[anonsec] multihoming and BTNS

[mcr at sandelman.ca (Michael Richardson)]

Black_David at emc.com wrote:
> Taking the areas in reverse order, the current sections 6.1 and
> 6.2 of the draft essentially say that NAT, mobility and multihoming
> issues are out of scope.  Whether they are out of scope is a longer
> discussion, but the approach agreed to in this afternoon's btns
> meeting is to remove Sections 6.1 and 6.2 from the problem and
> applicability statement draft, and deal with whether the issues
> are in scope and what to do about them if they are in the context
> of the WG's other drafts.

What could it mean for BTNS to be multihomed?

Let's assume that we have a ULP that deals well with being multihomed... 
SCTP, and it wants to use channel bindings to secure all of the routes.

A security concern might be that something like this might happen:


      +-------+ b2
      |   B   |---\
      +-------+    \ 2
       b1 |         \
          |        +-----+
          | 1      |  M  |
        a1|        +-----+
       +------+     /
       |  A   |----/ 3
       +------+ a2

Let's say we start the connection on link 1, using SCTP.
They do IPsec, and with a channel binding, bind link 1 (a1...b1)
SCTP exchanges addresses a2/b2, and at some point decides to failover to that 
link. Traffic across that link causes a new IPsec connection, but it is 
intersepted by M. As the application had used channel binding to offload the 
privacy and integrity protection to IPsec, the link through M can now be 
intercepted.

Either the application must become aware that a new channel binding is 
necessary, or the IPsec connection for a2...b2 must be related to the one for 
   a1..b1.

What this really means is that connection latching must in fact latch the
identities used in a1...b1 to identities to be used for a2...b2. This is 
really no different from the case where a1...b1 must be rekeyed. The new SA 
must use the same identities as the old one.

I don't think that the connection latching document addresses this issue
directly, but I think that it could spell out this case, and a connection 
latching capable SCTP stack would be able to do the right thing.

So, I don't have a problem keeping this in scope.