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

Re: 2nd try



Stephen Kent writes:
> >I think we should select the most secure protocol (i.e. case #3) as
> >MUST, and allow #2 protocol for high-speed implementations as MAY.
> #2 and #3 are equally secure in terms of IPv4. 

No they aren't equally secure.

If the policy is "allow only SMTP traffic go through", then using #2
will still allow any fragments go through. I do think two setups are
equally secure if the other setup allows packets which should not go
through to go through. It does not matter, that the final recipient
will then throw those packets away later, the packets did go through
the VPN link.

The difference in the secrity might not be that big, but it is there.
It for example offers very good covert channel through the vpn, and
after seen "IP over DNS", I think it does not take a long when someone
creates "IP over non-first fragments" protocol to get around the
restrictions in the VPN. Or someone creates peer-to-peer program that
runs on non-first fragments only just to get it working also through
VPNs which only allow SMTP traffic or similar.

> As Paul noted, it is a lot more difficult in hardware, especially at 
> very high speeds. My experience in designing such devices convinces 

I am not hardware person, so I cannot really comment on that, but
seeing what else they are currently doing on the hardware I do think
it is actually very easy to do on the hardware too (compared to the
other things they do there). One easy solution is to put the ARM core
or similar processor inside the hardware, add do it partly on
software.

> me of that fact, as much as your experience in developing software 
> has convinced you that it is not too complex in that context. (BTW, 
> was this software for an end systems or an SG?)

Our code is used for all possible cases, i.e. both in end system and
SGW, regardless whether the IPsec is inside the IP-stack (BITS), or
below it, or on the media level (BITW). It can also do full reassembly
on the systems where we get fragmented packets from the IP-stack and
we need to stuff them to transport mode SA etc. 

> How about a compromise? We could make #2 a MAY and #3 a SHOULD. A 
> SHOULD is almost a MUST, with a loophole as noted below (from RFC 
> 2119):

That would be accectable for me. 

> This would allow a hardware implementation to not support #3, if 
> doing so would adversely impact overall performance.

Ok. 
-- 
kivinen@safenet-inc.com