[Openswan dev] Openswan on uClinux
aparna.dutta
aparna.dutta at jasmin-infotech.com
Wed Dec 19 00:33:21 EST 2007
We are using NETKEY, but the packets that were not encrypted were NOT
non-initial fragments. Actually we were doing a small sanity-test to check
that when a connection is set up and data is transferred using
socket-programming between 2 machines connected by an IPsec tunnel, the
packets are indeed encrypted. The data that we transferred was in the order
of a few tens of bytes, and there was no fragmentation at all.
As Herbert says, on closer observation it appears that it is only an issue
with the Ethereal tool. I saw that when machines A and B are talking,
Ethereal on A shows (unencrypted) TCP packets received from B, but Ethereal
on B doesn't show the same being transmitted from B. Similarly in the other
direction.
So I understand this is not an issue regarding IPSec setup.
Thanks for your help,
Regards,
Aparna
-----Original Message-----
From: Herbert Xu [mailto:herbert at gondor.apana.org.au]
Sent: Wednesday, December 19, 2007 6:51 AM
To: Venkat Yekkirala
Cc: Paul Wouters; aparna.dutta; dev at openswan.org
Subject: Re: [Openswan dev] Openswan on uClinux
On Tue, Dec 18, 2007 at 02:42:13PM -0500, Venkat Yekkirala wrote:
>
> Actually even on NETKEY all xfrms should be applied BEFORE the
> packet ends up in ip_finish_output->ip_fragment, so frag/reassembly
> should be happening transparently (like they should). So, fragments
> shouldn't be going out in the clear. Is there a scenario where
> this isn't true?
You're absolutely corerct. I suspect what the original poster
was seeing is the fact that tcpdump on the receiver picks up
both the original encrypted packet and the decrypted packet which
is fed through the whole networking stack again.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert at gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
More information about the Dev
mailing list