[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (IPng 7212) RE: Last Call: Mobility Support in IPv6 to Proposed Standard
I think there is some confusion to what we are asking in regards to IPSec
and routing headers, Rich correct me if I am wrong. Sorry this is so long,
I want to make the example clear.
A mobile node is in its home network when it first establishes a security
policy with some correspondent node. The security policy in the
correspondent node uses the "home address" of the mobile node when
communicating. At a later time, the mobile node moves to another location.
The correspondent node still communicates with the mobile node using the
"home address" until the correspondent node discovers that there is a "care
of address."
The "care of address" is discovered when the correspondent node receives a
packet from the mobile node with the source address set to the "care of
address" and the packet contains a "Home Address" destination option. The
correspondent node caches the binding. The IPSec headers for this packet
could come before or after the destination option. If the IPSec is before
the destination option, then there must be an association between the "care
of address" and the correspondent node. If the IPSec is after the
destination header, the "home address" is used in the policy and no
association between the "care of address" and the mobile node exists. The
latter case is probably the most likely.
Lets take the example of the IPSec headers being after the destination
option. When the mobile node sends a packet to the correspondent node,
there is probably a security gateway protecting outbound traffic. The
security gateway communicates with the correspondent node. Here is a
diagram:
MobileNode("care of address")---->SG---->Internet---->CorrespondentNode
The traffic reaches the correspondent node which parses the packet and
creates the "care of address" binding. Then, the end-end IPSec between the
mobile node and the correspondent node is handled. Remember, the "home
address" is the destination address. It was swapped when doing the binding.
Now, the correspondent node sends traffic back to the mobile node. At the
transport layer, the "home address" is used for the policy lookup. However
if this is a TCP connection, the security association is probably cached in
the TCP control block so a lookup is not needed. Before the traffic is
actually protected by AH (AH because it covers the entire datagram), a check
of the binding is done to see if there is a "care of address." Yes, a "care
of address" does exist so the destination IP address is changed to the "care
of address" and a routing header created containing the "home address."
Of course, the routing header and the destination IP address are mutable but
predictable. The actual authentication is done on the predicted value.
This is one reason AH is so "fun" to implement and will cost in performance.
Before the traffic is sent, a policy lookup is performed to see if the
traffic is protected by IPSec. If a second policy lookup is not performed,
the traffic is dropped when it reaches the security gateway. So in this
case, it is necessary for the correspondent node to do a second lookup.
Unless of course, the security gateway looks at the routing header and
allows the packet to be forwarded to the mobile node. But this means the
traffic bypasses security at the security gateway. I doubt this is an
option.
Aaron
Original Message -----
From: Quaizar Vohra <qv@3com.com>
To: Richard Draves <richdr@microsoft.com>
Cc: <mobile-ip@smallworks.com>; <ipng@sunroof.Eng.Sun.COM>; <ipsec@tis.com>
Sent: Friday, February 19, 1999 8:29 PM
Subject: (IPng 7212) 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
>--------------------------------------------------------------------
>IETF IPng Working Group Mailing List
>IPng Home Page: http://playground.sun.com/ipng
>FTP archive: ftp://playground.sun.com/pub/ipng
>Direct all administrative requests to majordomo@sunroof.eng.sun.com
>--------------------------------------------------------------------
>
Follow-Ups: