RE: A basic question.

["Balaji K" <balajik@future.futsoft.com>]

Hi

Yes FTP are large packets. When a IPSec Router Recieves a packet of Size
1500 bytes the packet again needs to be Fragmented by IPSec because of the
OverHead Added by it (Size of the Packet will exceed 1500 bytes).
Safenet Client has to Reassemble the packet before decoding it.
It Seem's to be problem in some versions of SafeNet Client  with respcet to
reassembly .
SafeNet Client was not able to reassemble the Fragmented packets of Linux
Router (Linux IP Stack).
Even if you try a Ping from Host with more than 1500 bytes you will not get
a response from Safenet Client

Regards
Balaji.K


-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Roy, Gilles
Sent: Thursday, February 06, 2003 6:39 AM
To: Bepsy Paul
Cc: ipsec@lists.tislabs.com
Subject: RE: A basic question.



You may be having MTU problems. You ICMP packets are probably all very small
packets that don't need to be fragmented. The FTP packets are probably large
enough that when you add the extra tunnel headers they need to be
fragmented.

You can confirm if fragmentation is an issue by pinging with large packets.

Gilles

-----Original Message-----
From: Bepsy Paul [mailto:bepsy@airBB.com]
Sent: Wednesday, February 05, 2003 3:26 PM
To: ipsec@lists.tislabs.com
Subject: A basic question.


Hi,

  I am developing a VPN s/w for a small (9 engineers only) start-up company.
I have developed a VPN with only 3DES and SHA-1-96 support and for TUNNEL
mode. Now I am testing that with Safenet VPN client. My question is, the VPN
tunnel works well with ICMP. But when I try FTP, it's not working. Can
anyone point out any possible problem with FTP? I am processing ICMP, TCP
and UDP packets in the same manner in IPSec output packet processing
function. Your reply will be really appreciated. Bear with me for my simple
question as I am just starting with VPNs.

Thanks & Best Regards,
Bepsy

-----Original Message-----
From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On
Behalf Of Stephen Kent
Sent: Tuesday, February 04, 2003 6:02 PM
To: John Lindal
Cc: ipsec@lists.tislabs.com
Subject: RE: new to VPN


At 2:41 PM -0800 2/3/03, John Lindal wrote:
>  >>  > There's a very large difference between a general purpose OS
> like
>>>>   Windows or Unix, and an embedded system OS.  Large, as in several
>>>>   orders of magnitude.
>>>
>>>Unless I'm missing something fundamental, comparing the raw sizes of
>>>various operating systems is misleading.  Assuming that the VPN
>>>software
is
>>>installed at the bottom of the network stack, just above the NIC
>>>driver, then it doesn't matter how big the rest of the OS is.  The
>>>only thing
that
>>>matters is the tiny little bit of the OS that takes the packet off
>>>the
NIC
>>>and hands it to the VPN driver.
>>>
>>>Of course, this small part of the OS must not have any holes, the VPN
>>>software must not have any holes, and the security policies must be
>>>set correctly to weed out malicious or unwanted packets!
>>
>>  I'm afraid you are missing something. Irrespectivbe of where the VPN
>> software is installed in a general purpose platform/OS environment,
>> that software can be subverted by a successful attack against any
>> part of the rest of the OS.
>
>How can one attack the rest of the OS if the VPN component is located
>at the only entry point and doesn't allow malicious packets to pass?
>
>>  Your comment suggests that if the VPN access controls are working,
>> then  no evil packets can evade detection and thus be used to attack
>> the
higher
>>  layer software. We have lots of experience that indiactes otherwise.
>
>I think it's a matter of definitions.  In any situation where malicious
>packets get through the VPN filter, I would say that the access
>controls are not working correctly :)

John,

I've often joked that when I was on the IAB for over a decade I missed the
opportunity to define the "evil" bit in the IP header, which would flag
malicious packets and make security so much easier
:-)

I know of no way to determine if a packet is malicious, in absolute terms.
We characterize packets (or, more typically, sequences of
packets) as malicious only once we understand the bad things than can
happen, usually as a result of being the victim of an attack. So, detection
of malicious packets is, in that sense, a two pass algorithm, with a
possibly long with a possibly long interval between the passes.

I didn't think that any firewall or IDS vendor really believed that it had
filters or signatures or anomaly detection algorithms that were good enough
to detect all malicious traffic. Thus, by your definition, ALL of these
products have defective access controls.

On what basis do you believe that your technology is capable of detecting
and rejecting all malicious packets and thus is immune to attacks that might
traverse the VPN component?

Steve

P.S.  I think it would be better to not refer to functions like IDS as VPN
components.  The generally accepted terminology for VPNs is broad, bit I
don't think  most folks would claim that it encompasses Intrustion
Detection. One may choose to provide IDS functions in the same box as IPsec,
but the two are independent.

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************