[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: In tunnel mode why options are not copied to outer IP header
Padma,
Karen is away at a class, so I'll try to address your questions.
I think that the issues you are raising do not in general have a
simple, easy to describe and implement answer, so they were set aside
in the interest of getting the current version of the specifications
standardized. I hope that they will be addressed in IPSecond :-).
> 1) It is said that options are never copied to outer IP header from
> the inner IP header. Why is it so ?
Options have semantics, and in general, simply copying may not preserve
those semantics. One might need an option by option specification of
how it should be transformed when included in an encapsulating header.
Your next questions illustrate some of these issues.
> 2) According to that a user cannot have tunnel mode security between
> two endpoints along with strict routing (or any options). Is it so.
I say no, that is not the way I read the documents (but others may not
agree :-). Your question 1 is about copying options from an inner
header to an outer header -- something that a security gateway would
do. As I read question 2, it is about an end-to-end tunnel. In the
end-to-end case, any options would not be "copied", they would be
inserted as part of whatever IP layer processing is used to create the
tunnel header. Note that a source route in the inner header would
accomplish nothing, as the packet would already be delivered to the
endpoint by the outer header and source route.
> But having Strict routing along with security ( I am speaking in the
> context of tunnel mode ) provided, makes a lot of sense because we
> can avoid the datagram traversal along a previously known insecured
> route or a rival's router.
In the case of a security gateway to security gateway tunnel, there is
nothing prohibiting the inclusion of a source route in the outer
header, when the inner header does not include a source route. An
implementation may provide additional functionality in its policy
database that allows an administrator to specify parameters of tunnels
that it creates (whether the receiving security gateway would
associate such a source route with the tunnel for return traffic has
not been standardized -- but a return tunnel is a separate issue).
Traditionally, source routes have been viewed as dangerous since they
can be used to implement spoofing attacks. Now that we have IPSec to
protect the integrity of source routes implemented via a Routing
Header (but not the IPv4 option), maybe folks will view them as less
dangerous.
Note however, that neither integrity nor any other IPSec services or
mechanisms provides any assurance that the routers actually forwarded
the packet along the intended route -- one or more of the routers may
be untrustworthy or have been compromised. You would have to trust
each router in the strict source route -- maybe that is acceptable.
> 3) We are doing options processing after IpsecOutbound processing.
> In case of tunnel mode even though the hidden inner IP header had
> Options set as they are not visible from outer IP header, we are
> just processing as if no options was present in the inner IP
> header. Is this way correct.
I do not think so. First, a security gateway that is going to tunnel
a packet (with or without a source route) has to figure out where the
tunnel will end. This is the security gateway discovery problem. The
discovery mechanism would need to place (at least the unused portion
of) a source route into the discovery packet so that it would be
routed according to the source route. (Note that the security gateway
that is discovered using the source routed packet may not be the same
as would have been discovered were the source route not present --
that is to be expected.) The reply packet should include the source
route option / routing extension header as it was received at the
discovered gateway. Using that information, the encapsulator can
identify the remaining portion of the original source route, and can
partition it into the segment before the tunnel endpoints and the
portion beyond the decapsulator.
We might have to legislate whether the tunnel encapsulator or
decapsulator is responsible for making the inner destination IP
address and source route look right. I suspect that the most
deployable solution would be to assume the decapsulator does not do
anything special, so that the encapsulator must do the transform --
especially since it is the box that wants to use a source route.
Given that decision, when tunneling a packet, the inner source route
and destination IP address needs to be adjusted by the encapsulator to
appear as it would at the tunnel decapsulator: the inner source route
needs to be adjusted for all the hops that were processed by the
tunnel -- this is the motivation for having the source route returned
in the discovery packet. The IP address needs to updated accordingly.
The encapsulating IP header would need to include as its source route
the segment (if any) discovered to be between the security gateways
(end of tunnel).
I think it would actually be better better, for IPv4, if the
decapsulator updated the inner IP header and source route, as it can
more easily maintain the IPv4 source route semantics. Recall that for
IPv4, IPSec cannot even provide integrity for a source route - it is
mutable and cannot be predicted. The routing header is easier to handle.
> Even if option processing is done before Ipsecoutbound processing,
> options of the inner IP header will be processed before
> encapsulation by the IPSEC only at the sender, but the intermediate
> security gateways acting as just routers will not be doing any
> options processing at all. If this what is thought of?
This would work for the "copy inner source route to outer source route"
portion of the problem, but someone would still have to adjust the
inner source route and IP destination address to skip over the portion
of the source route between the tunnel encapsulator and decapsulator.
Its is all doable, but there are lots of details to get correct.
Let me know if I have skipped over too many details to make the above clear.
Other options might need their own analysis and processing rules.
Charlie