SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: trust security claims of incoming packets?



    Bill,
    Thanks for the confirmation that the spec requires verification of policy.
    I too have come accross more than one vendor who does not lookup the policy
    after ESP processing - they assume that this double-checking is redundant
    since a check already occurred when the Security Association was
    established. I had been somewhat willing to accept that although I now think
    this is also a security hole. 
    What I could not accept is not checking the policy at all when the packet
    arrives in the clear since in such a case there has been no prior check that
    the packet _should_ be in the clear.
    Vince
    
    
    |-----Original Message-----
    |From: Bill Strahm [mailto:bill@Sanera.net]
    |Sent: Wednesday, October 24, 2001 2:50 PM
    |To: CAVANNA,VICENTE V (A-Roseville,ex1); ips@ece.cmu.edu
    |Cc: SHEEHY,DAVE (A-Americas,unix1); ALBERTSON,LYLE (A-PaloAlto,ex1)
    |Subject: RE: trust security claims of incoming packets?
    |
    |
    |I can't vouch for other implelmentors, but the implementation 
    |I worked on
    |checked... It is required in the specification.  This 
    |basically turned into
    |a single look into a hash table... not a huge overhead... some, but not
    |much, and we were able to get darned close to theoretical wire speed at
    |100Mbps full duplex...  I know that some vendors did not check 
    |after ESP
    |processing if the packet should have been covered by the 
    |negotiated SA...
    |We didn't initially, we did in a second version that never 
    |made it to market
    |(to my knowledge)
    |
    |I'd like to know what vendors you talk to that don't follow 
    |the standard, I
    |can actually see many VPN vendors not doing this, because they 
    |will turn
    |around and drop all clear packets anyway...
    |
    |Bill
    |+========+=========+=========+=========+=========+=========+=========+
    |Bill Strahm     Software Development is a race between Programmers
    |Member of the   trying to build bigger and better idiot proof software
    |Technical Staff and the Universe trying to produce bigger and better
    |bill@sanera.net idiots.
    |(503) 601-0263  So far the Universe is winning --- Rich Cook
    |
    |-----Original Message-----
    |From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    |CAVANNA,VICENTE V (A-Roseville,ex1)
    |Sent: Wednesday, October 24, 2001 1:46 PM
    |To: 'ips@ece.cmu.edu'
    |Cc: CAVANNA,VICENTE V (A-Roseville,ex1); SHEEHY,DAVE 
    |(A-Americas,unix1);
    |ALBERTSON,LYLE (A-PaloAlto,ex1)
    |Subject: trust security claims of incoming packets?
    |
    |
    |Most vendors of IPSec components that I have talked to do not verify,
    |against their local policy database, if an inbound packet has 
    |claimed and
    |been afforded the security processing that the local policy 
    |specifies. Doing
    |this verification may, of course, introduce a performance 
    |bottleneck in the
    |processing of unsecured packets which would be undesireable, 
    |as most users
    |would expect performance not to degrade unless secured packets 
    |are being
    |processed.
    |
    |If a packet arrives demanding security processing (e.g. has an 
    |ESP header)
    |then, after processing, the local policy is inspected to 
    |confirm that the
    |appropriate processing was applied  but if the packet arrives 
    |unsecured  all
    |security processing is bypassed, trusting instead that the 
    |packet was indeed
    |meant to be insecure.
    |
    |This method of handling unsecured packets goes against my 
    |interpretation of
    |the IPSec specs and seems to be a security hole.
    |
    |What point am I missing that will mitigate my concern?
    |
    |Thanks.
    |
    |Vicente Cavanna
    |Agilent Technologies
    |
    


Home

Last updated: Thu Oct 25 13:17:30 2001
7394 messages in chronological order