[anonsec] multihoming and BTNS
mcr at sandelman.ca
Wed Jul 25 23:37:40 PDT 2007
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:
| B |---\
+-------+ \ 2
b1 | \
| 1 | M |
| A |----/ 3
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
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
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.
More information about the ANONSEC