RE: SAs that carry fragments Was: Re: Some IKEv2 issues

["Bora Akyol" <bora@cisco.com>]

Thanks Charlie, please see in-line.

> The WG rejected the idea of a *separate* SA for fragments.
> 
> We are now talking about how to indicate that an existing SA 
> should be used to carry fragments, that is interoperable (can 
> be communicated via IKEv2) so that the packets the sending 
> implementation puts into the SA will be consistent with the 
> receiver's access control policy (SA).

Just like the sender can handle the fragments
without requiring a separate SA, the receiver can also handle
the fragments without a flag that says this SA carries fragments,
please let them pass without checking SP. This IMHO, looks too much
like a hole that someone will eventually exploit for some reason.
Is this what the opaque stuff is about? And isn't all of this stuff
considered unnecessary with IPv6?

> 
> It requires memory in, e.g., a security gateway, code to do 
> fragmentation and reassembly, and makes it harder to keep up 
> with line rate.
> 

Yes, more buffers may be required, but not that much harder to keep
up with line rate at the sender or receiver. 
Especially in the scenarios that have been
given on this thread which are mostly host, this should not be an issue.

> > Queue fragmented packets for reassembly remembering what SA 
> protected 
> > each fragment, then when the packet is reassembled, and if all 
> > fragments were protected by the same or congruent SAs check SPD, 
> > otherwise drop.
> 
> Is this at the sending end of the IPsec channel or the 
> receiving? I.e., "what SA protected each fragment" sounds 
> like the receiver. If the fragments got that far, a solution 
> that protects fragments is assumed, but not identified.
>

I noticed this too, the conversation that I am interested in is in the
sender.
 
>
> The suggestion I made does not require any copies, and dos 
> not double the number of SAs.
> 
> > No, but the standards should be simple, clear and easy to implement.
> 
> Agreed.
> 

Thanks.
> > Adding features that improve the protocol coverage by 0.01% while 
> > increasing code complexity by 1-3% is hardly worth the effort.
> 
> Where did you get these numbers?
> 

The numbers were an example based on my software engineering expertise.
Most bugs that I have seen come from corner cases or rarely used
features
that one almost never sees in the field. In order to support these
features,
the code bloats, ... I can go on and on about this.

> > I think we should aim to cut rarely used features off 
> existing IPSEC 
> > standards as opposed to adding to the feature set. 
> Generality is good 
> > but it comes at a cost of implementation complexity, 
> interoperability 
> > problems and deployment headaches.
> 
> Not always.
> 
> > I think the traffic selectors and their broad flexibility is one of 
> > these features.  For example just by cutting port based 
> selectors for 
> > TCP and UDP, cost of doing security policy checks goes down 
> > exponentially for most software and linearly for most HW. This has 
> > huge scalability benefits if ever IPSEC is going to get widely 
> > deployed.
> 
> Well, not using port selectors might make sense for VPNs, but 
> IPsec is designed for more than just VPNs.
>

How does a policy maker (say an IT mgr) decides that port 8001 is more
valuable
than port 8002. And what happens to the renagade user that runs a web
server
on port 16032? This is precisely why the TCP/UDP port based selector
spefication
is more eye candy than anything. The kernels today allow so much
flexibility
on what application can bind to what ports that it does not make sense
to
secure one application in a different manner than another. They should
ALL 
be equally secure. Otherwise, this one clueless insider will find the
port
that is being secured by DES and set-up the most critical infrastructure
on that port.


> > I am sure at some point before the 2401bis and IKE V2 efforts were 
> > under way, there must have been a deployment survey 
> performed. If that 
> > is the case, then we should look at that and cut the 
> features that are 
> > not used at all, cut features that are rarely used and 
> agree on a core 
> > set of features and specify these clearly from both protocol and 
> > management perspectives.
> 
> That sort of assumes that past usage is a good predictor of 
> future use. I think that the Internet has proven that not to 
> be the case more than once.
> 

OTOH, IETF requires a deployment study before an RFC becomes
an STD, if I remember correctly. I always find it worthwhile to look
at what's in the field and then prioritize work accordingly.

So if I were writing the traffic selector spefications, I would write
them in an extensible format based on the following:

IP DA, SA, IP proto are on by default for v4 and v6.
Then there are optional selectors defined by offset from the end of
a well known field (say IP version number) and field length. They
could mean anything. 

This way one can get as specific as they want, but most common
uses will get the simplest possible implementation.
This type of field selector specification is used frequently
in network processor designs where such a lookup would be a single 
instruction.

Bora