Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt

From: [email-masked]
Date: Thu, 2 Aug 2001 00:04:23 -0500

>I'm trying to make the point here that the BU protection and key
>management can be solved in an independent manner. I wasn't
>actually thinking that IKE be used to create MIP-specific SAs.
>That would also be possible, though it involves some more work.
>
>Instead, I think a much more fruitful approach would be the following:
>
>- CN, MN, and HA nodes implement AH protection for BUs in the manner
>  discussed before in this thread i.e. no piggybacking and a new
>  next header number. Current IPsec suffices for this.
>

If you have a new next header number, would you still need to avoid
piggybacking?
(Maybe I should go read this really long thread and find the answer...)

One of the things that has been raised as a concern is the scalability
of IPSec SAs in CNs (such as web servers) which may be serving a large
number of MNs. Can today's IPSec implementations handle a very large
number of SAs in the SAD (in the tens of thousands)? 

>- CN and MN nodes implement BAKE - or something similar -
>  in order to generate keys without a global PKI. BAKE provides
>  keys for AH i.e. creates IPsec SAs. We do need to complete
>  BAKE in this WG, but I don't think it'll make a difference whether
>  it keys IPsec SAs or other kinds of SAs.
>

Good. Relying on IPSec SAs as the only types of SAs may be a limiting
factor. 

>- Optionally, some nodes may implement IKE in order to 
>  use it for VPNs or for the protection of BUs through a
>  corporate PKI. Of course IKE will also be creating
>  keys for IPsec SAs.
>
>Jari
>

-Basavaraj

---

From: Jari Arkko <[email-masked]>
Date: Thu, 02 Aug 2001 14:54:15 +0300

>If you have a new next header number, would you
>still need to avoid piggybacking? (Maybe I should
>go read this really long thread and find the answer...)

It is indeed a long thread! I think the answer
is that piggybacking would still have to be avoided.
Both in terms of firewalls and ipsec policies the
current limitation is that usually just one level
of protocols can be matched against. The remaining
part of the packet beyond the BU might include something
that needs other special security treatment. Again,
this is an limitation that could relatively easily be
removed, but in this discussion we were trying to
see how BUs must look like if current IPsec is used.

>One of the things that has been raised as a concern
>is the scalability of IPSec SAs in CNs (such as web
>servers) which may be serving a large number of MNs.
>Can today's IPSec implementations handle a very large

The scalability issues certainly deserve some thought.
There are IPsec implementations that can handle
large number of SAs. There are also implementations
that handle only a few. If you are out of luck, it's
on your web server OS ;-) Seriously though, there are
three separate issues, the SAs themselves, their use,
and then the policy databases. Let's discuss the SA database
first. This is in the order of a few hundred bytes
in typical implementations and essentially contains
the necessary cryptographic contexts, plus a small
number of other smaller fields. Any SA, IPsec or
other, requires similar amounts of memory. So
here it is hard for me to see an issue.

Naturally there might be hard computing power
limits on how much you can actually use the SAs.
These should also be roughly similar in any of
the alternatives we are discussing. It is perhaps
possible that on some busy servers this load
exceeds the capabilities of the hardware. It is
likely that server manufacturers would like to
add a feature that enables the box to age BUs
faster and/or refuse BAKE and optimized routing
if the load of the box grows too high.

Finally, the policy databases that contain the
filters to match packets. These need both memory,
and execution time for each packet. Typical
implementations would perhaps use a similar amount
of space for a policy entry as they do for an
SA. On a MIP-specific solution, we don't need 
this as the policy is in a way hardcoded to the
processing of the BUs. However, assuming your
box doesn't want to support IPsec in general
and only wants to support BU protection, it
is easy to optimize this by e.g. starting
the policy matching only in the BU processing.

Jari