[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 2401 section 5.2.1
----- Original Message -----
From: "Francis Dupont" <Francis.Dupont@enst-bretagne.fr>
>
> Why not? It can do everything transport mode does. (In particular, it
is
> perfectly capable of working host-to-host.)
>
> => the price (in complexity, in overhead in packets, ...) is not the same.
> This is like the tunnel/routing header issue and IMHO should have the same
> kind of solution:
> - if you cannot use a header then you must use a tunnel
> - if you can use a header then you should use it.
> With you must not modify packets in route this gives headers (transport
mode
> for IPsec, routing header and home address option for mobility, ...) for
> end-to-end operation and tunnels for other cases.
> I really believe the end-to-end principle asks for the transport mode,
> and the tunnel mode is a half-wedding (a PACS in French :-) between IPsec
> and generic tunnels.
>
Transport mode does not solve the end-to-end security problem.
In fact, either mode of IPSec cannot traverse NAT and is not
capable of providing end-to-end security. One exception is the
LAN configuration where you do not have to deal with NAT. There,
one can use the transport mode for end-to-end security. A whole
lot of work has been done to address this problem, e.g. RSIP,
UDP encapsulation etc.
For a discussion of the end-to-end security problem, take a look
at this draft. In there you will also find references to other work
done on end-to-end security problem.
http://www.ietf.org/internet-drafts/draft-shukla-ipsec-nat-qos-compatible-se
curity-00.txt
~Jayant
Follow-Ups:
References: