[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.
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
Follow-Ups: