Sabahattin Gucukoglu wrote:
nor IPv6, especially because NAT can be end to end transparent.
How do you propose to make end-to-end crypto of packets possible
where NATs are involved?
My proposal in draft-ohta-e2e-nat-00.txt is to use 32 bit SPI as
16 bit source and destination port numbers:
The same location may be usable for some protocols. For example, ESP
packets may be demultiplexed based on the lower 16 bit of SPI. To do
so, a destination host must be able to control the lower 16 bit of
SPI.
Other protocols may use different location, for which E2ENAT may
provide special care. Considering that an ICMP packet generated
against an IP packet contains only the first 64 bits of payload of
the original packet, demultiplexing information for source transport
is implicitly assumed to be located in the 64 bits. So, it is natural
that demultiplexing information for destination transport is also
located in the same field. If the information is 16 bit word and 16
bit aligned, there are only four variations on the location. This
memo assumes so.
For example, AH packets may be demultiplexed as if the lower 16 bit
of SPI, located at the seventh and eighth bytes of a payload, is a
destination port number.
Though existing NAT boxes may not support such behavior, upgrading
is necessary only by those who want to use IPSEC behind NAT.
I'm assuming you think everything can be solved with signalling,
yes? I ask because NPT could be the end of it if we all agreed
to use the right kind of signalling.
Signaling between what?
SPI negotiation may be called signaling.
Masataka Ohta