From: "H. Peter Anvin" <hpa@zytor.com>
To: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: "Stephen J. Bevan" <stephen@dino.dnsalias.com>, netdev@vger.kernel.org
Subject: Re: ProxyARP and IPSec
Date: Mon, 04 Sep 2006 22:12:57 -0700 [thread overview]
Message-ID: <44FD0759.8070307@zytor.com> (raw)
In-Reply-To: <20060904222722.GA24078@ms2.inr.ac.ru>
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
next prev parent reply other threads:[~2006-09-05 5:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-23 0:31 ProxyARP and IPSec H. Peter Anvin
2006-08-23 19:14 ` Thomas Graf
2006-08-23 22:14 ` David Miller
2006-08-23 23:18 ` Alexey Kuznetsov
2006-08-24 1:12 ` H. Peter Anvin
2006-08-24 1:14 ` H. Peter Anvin
2006-08-24 2:20 ` Andy Gay
2006-08-24 4:14 ` H. Peter Anvin
2006-08-24 12:50 ` Alexey Kuznetsov
2006-08-26 4:16 ` H. Peter Anvin
2006-09-02 15:36 ` Stephen J. Bevan
2006-09-02 17:30 ` H. Peter Anvin
2006-09-02 20:54 ` Stephen J. Bevan
2006-09-05 5:17 ` H. Peter Anvin
2006-09-04 22:27 ` Alexey Kuznetsov
2006-09-05 5:12 ` H. Peter Anvin [this message]
2006-09-05 9:05 ` Alexey Kuznetsov
2006-09-22 20:36 ` David Miller
2006-09-23 4:22 ` Stephen J. Bevan
2006-09-06 2:25 ` Stephen J. Bevan
2006-08-24 10:50 ` Thomas Graf
2006-09-07 22:28 ` H. Peter Anvin
2006-09-08 7:37 ` Thomas Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44FD0759.8070307@zytor.com \
--to=hpa@zytor.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@vger.kernel.org \
--cc=stephen@dino.dnsalias.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).