[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
m-to-m multicast and SAs
Hello everybody,
I am new to the ipseC mailing list so you will forgive me if this topic has just
been discussed. Your feedback together with pointers to any previous discussion
are welcome.
Kent & Atkinson said in RFC 2401 :
"[...] A security association is uniquely identified by a triple consisting of
a Security Parameter Index (SPI), an IP Destination Address, and a security
protocol (AH or ESP) identifier [...]"
In my opinion this definition omits an attribute, which I call *direction*, that
in particulare cases (and among these some interesting multicast typologies) is
indispensable for a correct SA identification.
It seems that there is an implicit hypothesis that Sender and Receiver are
*distinct*.
This is certainly true in the typical case of unicast transmission, and in
multicast contexts where transmission is really 1-TO-M, but not in the more
general case.
Let's start considering this unicast pathologic case:
S ---------------> S
SA[1]
SA[1] = <S, SPI[1], PROTO[1]>
If we look at it 'from right', the direction is INBOUND and it is possible
to correctly determine it on the basis of the *IP Destination Address*
attribute; See algorithm :
if ( dst == MYADDR ) direction = IN
else direction = OUT
But if we apply the same reasoning 'from left' we should conclude that direction
is still INBOUND, where it isn't.
We have two conceptually distinct objects but not enough attributes to discern
them.
The situation just considered has a significant impact in Multicast/Broadcast
transmission schemes for which we wish to use the security mechanisms offered by
IPsec and where Senders are potential Receivers and vice versa (so that SA
relationship includes the loop s----->s).
Multicast example:
Taken m, member of the multicast group M, we want to protect outgoing
traffic to M.
We need a SA as :
m ---------------> M
SA[2]
SA[2] = <M, SPI[2], PROTO[2]>
If m does not recognize M address as belonging to its, SA[2] behaves exactly
as SA[0] and there should be no problem in applying it to the outgoing
packets to the Multicast group.
Consider now the specular situation by which we would ensure the traffic
generated by group members and received by m (under the same algorithm-key).
m <--------------- M
SA[3]
Now SA[2] == SA[3] (protocol identifier and SPI are the same because ingoing
and outgoing traffic must be processed under the same (inverted) functions,
and destination is in both cases M)
Again we have two distinct SAs (SA[2] OUTBOUND and SA[3] INBOUND) but we
can't discern them as they correspond to the same tuplet.
Conclusion:
The actual definition of SA doesn't apply to the point-to-multipoint case.
We thought of two solutions for this problem:
The first extends the definition of SA adding the attribute Direction (SA*),
the second sets a new semantics for multicast addressing (MVH, Multicast Virtual
Host).
SA* = SA + Direction
This modifies specs in RFC2401 : "[...] A security association is uniquely
identified by a tuple consisting of a Security Parameter Index (SPI), an
IP Destination Address, a security protocol (AH or ESP) identifier, and a
Direction[...]"
Multicast Virtual Host
We map the group address to a Multicast Virtual Host:
All the traffic from m to the group is directed to MVH, whereas the group
traffic intercepted by m *comes* from MVH.
In this way actual definition of SA can easily support multicast,
but not the unicast 'pathologic' case.
Note that RFC1122 [Braden] is not contraddicted: address translation is done
locally and no datagram on the net has a multicast source address:
MVH only exists in a sw layer between IP input routine and IPSec engine:
if ( IS_MULTICAST(iphdr.dst) ) {
ipFAKEhdr.dst = MYADDR;
ipFAKEhdr.src = iphdr.dst;
...
}
Please tell me where I go wrong.
THomas
Follow-Ups: