[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


 > > I am sorry I was unclear in my last mail. When I said that SG will not
 > > do inbound IPSEC processing, I did not mean that it will not check its
 > > policies to see if the packet should have come encrypted to it
 > > If it has such a policy, it should drop the packet.
 > > 
 > > Eric already clarified this.
 > > 
 > > The intention of my previous mail was to say that the presence
 > > of source routing header in a packet should not change the IPSEC
 > > behavior either at the inbound or outbound. While a routing
 > > header might be considered as part of policy lookup, if an
 > > implementation allowed defining IPsec policies filtering on
 > > intermediate destination.
 > 
 > I'm trying to keep things "simple" and not even consider policies that
 > filter on routing headers.
 > 
 > So are we in agreement that an IPsec-enabled node that is processing a
 > routing header should do inbound & outbound IPsec processing, much like a
 > security gateway that is forwarding a packet? Then I don't understand the
 > point you are trying to make.

Yes I agree, but only that it should not consider SG as part of the
selector, but the final destination, unless policies have capabilties
to include intermediate destinations as part of the selector list. 
I guess this is implementation dependent.

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

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

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.

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.

Quaizar


 > 
 > One thought that occurs to me: to revisit the example of a node SG that
 > receives a packet
 > 	IPv6 hdr - src A, dst SG
 > 	Routing hdr - segs left = 1, B
 > 	Transport hdr
 > 
 > When node SG is doing its inbound SPD lookup, what selectors should it use?
 > Should the destination address selector be SG or B? In my first email on
 > this subject I argued for SG, but now I'm thinking perhaps the destination
 > address selector in inbound processing should be B (the destination address
 > after routing header processing).
 > 
 > Thanks,
 > Rich
References: