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

RE: Traffic selectors, fragments, ICMP messages and security policy problems



Hi

While I agree with your general statement, if the question is whether
the RFC2401
(bis) is implementable at "very high speed" then the answer is yes. I
was in a development team for such a high speed implementation during
the last couple of years (this stated here not to claim knowledge over
ALL implementations but
as to describe my personal experience).

Can we build even faster hardware and cheaper with a basic subset of
traffic selectors then don't require 5 tuple lookups. My answer
to that is also yes again based on my experience. Heck even if we
allowed port ranges but limited them to masks, this would still result
in efficiencies in hardware based lookups, but will not solve the hw
problem.

While adding port ranges, etc is great and is applicable in 
a percentage of applications (example. secure only logging traffic
between two hosts, thanks to someone on this list for bringing this up),
if one can build 10 Gbps hardware with this specification, it is likely
possible to build 40 Gbps hardware with a much concise set of features.

With Ipv6 only hosts are allowed to fragment and PMTU is required so
this issue is unique to IPv4, and if all 2401bis hosts+SGs are required
to be compliant with path MTU discovery, then 
is there still a problem?  In your example, PMTU discovery should take
care of the reception of a 1500 byte ethernet frame and then running out
of space. Instead, the SG should sent the correct ICMP message which
should make the host reduce the MTU automatically (at least in this
ideal world :-) 

I guess we almost need a "capability negotiation" as part of IKE
and then define subset of capabilities for different types of
hosts/gateways.
This way, you can do both. Kind of like BGP capabilities.

Regards,

Bora


> -----Original Message-----
> From: Mark Duffy [mailto:mduffy@quarrytech.com] 
> Sent: Thursday, March 18, 2004 9:36 PM
> To: Bora Akyol; 'Tero Kivinen'
> Cc: 'Michael Richardson'; ipsec@lists.tislabs.com
> Subject: RE: Traffic selectors, fragments, ICMP messages and 
> security policy problems 
> 
> 
> Hi Bora,
> 
> I don't want to put numbers to it because I don't think they 
> matter.  I 
> would simply characterize a "high speed" implementation as 
> one pushing the 
> current limits of the technology at any point in time.
> 
> For any speed and price range, it will always be "easier" 
> (more feasible, 
> cheaper, faster for the price, shorter time to market, etc. 
> -- pick your 
> metric) to build a device that treats each packet (or 
> fragment) on its own 
> than to build a device that treats packets based on other 
> packets that have 
> been or will be seen.
> 
> A requirement to collect fragments in order to evaluate port selector 
> policy will serve to reduce the availabilty of high speed 
> implementations.
> 
> Mark
> 
> 
> At 05:30 PM 3/18/2004 -0800, Bora Akyol wrote:
> >Mark
> >
> >Can you please qualify what you mean by high speed and also how many 
> >tunnels at that speed?
> >
> >Do you mean 1Gbps, 10 Gbps or 100 Gbps? How many tunnels at 
> that speed 
> >and packet size.
> >
> >Once we define what "high speed" means, hopefully we can get a good 
> >understanding of what are the issues that are detrimental to 
> the high 
> >speed implementation.
> >
> >Thanks
> >
> >Bora
>