Alexey Kuznetsov wrote:
sarcasm mode is not accepted. Linux does exactly "standard tunnel-mode IPsec".
It does not give you device to make you totally happy.
The sarcasm was a commentary to the "just switch protocols then" comment.
Probably, you are not aware that "standard IPsec tunnel device",
if it is created:
1. Probably, will not accept fragmented frames, because IPsec cannot
handle them
Now that's interesting. If this is true, and I have every reason to
believe you know what you're talking about, then that would seem to be a
problem which is hard to overcome for any security gateway, regardless
of how it's implemented in the kernel -- the data originator might be on
a totally different host!
Furthermore, it seems to directly contradict the following statement
from RFC 4303 section 3.3.4:
"In tunnel mode, ESP is applied to an IP packet, which may be a fragment
of an IP datagram."
That reading seems to imply that it should handle fragments just fine.
Similarly, RFC 4301 section 13 ("differences from RFC 2401") states:
"For tunnel mode SAs, an SG, BITS, or BITW implementation is now allowed
to fragment packets before applying IPsec. This applies only to IPv4.
For IPv6 packets, only the originator is allowed to fragment them."
(consistently with the overall IPv6 architecture.)
Transport mode is different, of course.
2. Probably, will have undefined MTU (65536), because of 1
3. Probably, will screw up TCP because of 2
etc.
Actually, this is the reason why it is not implemented.
It is dirty business. :-) And the person, who implements this,
has to be really... unscrupulous. :-)
I'm clearly failing to understand where, exactly, the problems lie. I
would appreciate any pointers and/or clue transfusion...
-hpa
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
