[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(IPng 7222) Re: Last Call: Mobility Support in IPv6 to Proposed Standard
Richard Draves writes:
> > 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.
>
> See example below arguing that inbound IPsec processing should be required
> for intermediate destinations.
>
> > 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.
>
> There are two approaches to my questions about the interaction of routing
> headers and IPsec - the first is to think generically about routing headers,
> and the second is to think specifically about mobility scenarios. The
> mobility scenarios are good because they are very concrete, but they use the
> routing header in a very stylized way.
>
> In a later message I'll examine some more mobility scenarios. To get back to
> this particular thread, which is about more generic routing header
> scenarios:
>
> I don't understand how it can be legitimate for an IPsec-enabled node that
> is receiving a packet with a routing header to bypass inbound IPsec
> processing.
>
> A very concrete, simple example: consider a node SG. SG has two interfaces,
> an interface to the public network and an interface on a private network.
> Node A is on the public network and node B is on the private network. The
> SPD on SG requires all traffic through it to & from the public network to be
> protected with tunnel-mode ESP. This is a classic security gateway scenario.
> So in the normal case when node A sends a packet to node B, it will look
> like
> IPv6 hdr - src A, dst SG
> ESP
> IPv6 hdr - src A, dst B
> Transport hdr
>
> This packet will arrive at SG. The outer IPv6 header will be processed. The
> ESP header will be processed. The inner IPv6 header will be processed and SG
> will realize it needs to forward the packet. It will do an inbound SPD
> lookup and verify that the packet was protected with the appopriate
> tunnel-mode ESP security association, which it was. Then it will do outbound
> SPD processing, which will find a policy allowing the packet to be sent
> without further protection, and it will send the packet as
> IPv6 hdr - src A, dst B
> Transport hdr
>
> That's all well and good and I hope we are in agreement so far.
> Now suppose SG receives a packet that looks like
> IPv6 hdr - src A, dst SG
> Routing hdr - segs left = 1, B
> Transport hdr
>
> Now you are saying that SG should not perform any inbound IPsec
> processing?!? This would mean that SG will send the packet on to B without
> having verified that it was properly protected, bypassing the intended
> security policy.
>
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.
Quaizar
References: