RE: A basic question.

["Roy, Gilles" <Gilles.Roy@arc.com>]

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.