[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard

> The point I was trying to make in my first mail, was that if A
> is communicating with D via B and C, the resulting packet
> looks like
> 
> 	IPv6 hdr - src A, dst B
> 	Routing hdr - segs left = 1, C, D
> 	Transport hdr

[I think you mean segs left = 2 in this example.]

> Then it does IPSEC processing. Depending on the policy (irrespective
> of how detailed the selector list) lookup, chooses a policy, which
> directs it to either do tunnel mode IPsec with an SG or transport
> mode IPSEC with D.
> 
> In the 1st case, the packet will look like :
> 	
> 	IPv6 hdr - src A, dst SG
> 	ESP Tunnel mode with SG
> 	IPv6 hdr - src A, dst B
> 	Routing hdr - segs left = 1, C, D
> 	Transport hdr
> 
> In the later case, it will be
> 
> 	IPv6 hdr - src A, dst B
> 	ESP transport mode with D
> 	Routing hdr - segs left = 1, C, D
> 	Transport hdr

Surely you mean
	IPv6 hdr - src A, dst B
	Routing hdr - segs left = 2, C, D
	ESP transport mode with D
	Transport hdr 
?

> The secure gateway processes the 1st case by doing inbound IPSEC, 
> processing the ESP header. Next it processes the routing header 
> and forwards the packet to C.
> 
> In the 2nd case, if SG had an IPSEC policy that expected anything
> received on the interface this packet is received as ESP tunnelled,
> then it would drop the packet.
> 
> All I was trying to say is that a routing header should not mean that
> IPSEC outbound processing be done twice, one with selector D, and next
> with selector B. IPsec processing should be done once, with both B and
> D as part of selectors. Or only D, if selectors containing 
> intermediate
> dests are not supported.

Consider the following scenario. Nodes A and C are on a public network.
Their security policies let them communicate without a security association.
Node B is on a private network, connected to the public network by a
security gateway SG. The security policies on SG mandate that any traffic
between the two networks must be protected with tunnel-mode ESP on the
public side.

Now for some reason, node A wants to send a packet to C with a routing
header that will take the packet from A to B to C. The packet will need to
look like:
	IPv6 hdr - src A, dst SG
	ESP tunnel mode, association A -> SG
	IPv6 hdr - src A, dst B
	Routing hdr - segs left = 1, C
	Transport hdr

When this packet arrives at B, it will look like
	IPv6 hdr - src A, dst B
	Routing hdr - segs left = 1, C
	Transport hdr

Node B will process the routing header and send this packet:
	IPv6 hdr - src A, dst C
	Routing hdr - segs left = 0, B
	Transport hdr

The packet will get to SG again because SG is the router between B and C. SG
will send the following packet:
	IPv6 hdr - src SG, dst C
	ESP tunnel mode, association SG -> C
	IPv6 hdr - src A, dst C
	Routing hdr - segs left = 0, B
	Transport hdr

How does all that sound? Now go back to the packet sent by A. How will it
know to do the tunnel-mode ESP to SG? It will need to do outbound IPsec
processing with a destination address selector of B, and pick out the
security association with SG.

> So when a mobile node moves beyond a SG, how does a correspondent know
> that and hence configures a policy to do IPSEC tunnel mode with SG ?
> Rather, I would assume that such SGs who expect mobile nodes to enter
> their domain, would have policies which would allow traffic which is
> IPSECed (by the presence of IPSEC headers) but not destined for them.

If a mobile node moves beyond a SG, then a correspondent can know that
because the correspondent will learn a care-of address for the mobile and
the correspondent can have a security policy that tells it how to send to
the care-of address.

Thanks,
Rich
Follow-Ups: