[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(IPng 7211) RE: Last Call: Mobility Support in IPv6 to Proposed Standard
Rich,
>
>
> I believe that an IPsec-enabled node that is processing a routing header
> with non-zero Segments Left should do inbound IPsec processing (SPD lookup &
> policy verification) when it gets to the routing header and outbound IPsec
> processing before sending the updated packet. This should be just the same
> as a security gateway that is forwarding a packet. The routing header should
> not make it possible to bypass security policies.
I would think that if the intermediate dest (defined per the routing
hdr) gets an IP packet, it should not do inbound IPsec processing, as
it is not the final dest for the packet, i.e it is not one of the
endpoints of the IPSEC session. On the otherhand, if the packet was
tunnelled to it then it would make sense to do inbound IPSEC
processing.
Security gateways only operate on tunnelled packets, destined to it.
I agree that it is not the final destination, but is in the sense
of the IPSEC session.
Yes if the intermediate dest (one of the intermediate IP addresses in
the routing header) is a security gateway, it should do the outbound
IPSEC processing.
>
> Carrying forward the analogy with security gateways, the IPsec processing
> associated with a routing header should only support tunnel-mode
> associations. Otherwise it makes life too difficult for the node processing
> the routing header, because it would have to be finding & removing &
> inserting headers in strange places. Security gateways must only support
> tunnel-mode associations.
>
> To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a
> packet with a routing header through nodes B and C to node D. Node A can
> have tunnel and/or transport mode associations with node D, say for example
> transport-mode AH. Node A can only have a tunnel mode association with node
> B, say for example tunnel-mode ESP.
>
> The packets sent by node A will look like
> IPv6 hdr - dst B, src A
> ESP
> IPv6 hdr - dst B, src A
> Routing hdr, segments left = 2, addrs C, D
> AH
> Transport hdr
>
I would assume that each associations are related with some policies,
which classify based on some fields in the packet.
If node A has an association with D for this particular flow, then I
am not sure if it needs to have another policy for the same flow
which requires a tunnel mode security association with B and vice versa.
A default policy which requires a tunnel mode association for any
packets between A and B, should not be applicable either, as B is not
the actual destination for this packet.
> There might be further tunnel-mode associations between nodes B & C, nodes C
> & D but node A won't know about that.
>
> Note that this means that outbound IPsec processing on node A has to happen
> *twice*, first for the final destination node D, and then again for the
> first intermediate destination node B.
I don't understand why it should happen for the intermediate dest B, unless
you have a policy which says that for all packets destined to intermediate
destination B, use a tunnel mode association with B.
Here your processing of the packet looks like as if it was originated
twice, once as destined to D, and then destined to B. To me, it seems
better to consider the packet as originated once, destined for D.
I am not sure if routing header should be given the same semantic as
a tunnelling header, in the IPSEC context.
Sorry, if I am way offtrack in my understanding of this debate.
Quaizar
>
> Does this sound reasonable?
>
> Applying this to the mobility case, there's only one intermediate
> destination address and the final destination and the intermediate
> destination address happen to both be assigned to the mobile node.
>
> Suppose the correspondent node has an active transport-mode AH association
> for a TCP connection with the mobile node. Then the mobile node wanders off
> and acquires a care-of address behind a security gateway. The correspondent
> node needs to use tunnel-mode ESP to the security gateway to reach the
> care-of address, and then transport-mode AH for the home address.
>
> This demonstrates the example above: when the correspondent node sends to
> the mobile node, it needs to do outbound IPsec processing twice, first for
> the home address, then for the care-of address.
>
> Thanks,
> Rich
References: