Subject: Re: Scalability [Was Re: [mobile-ip] Drafty draft about key ...

From: Mohan Parthasarathy <[email-masked]>
Date: Tue, 27 Mar 2001 09:10:16 -0800 (PST)

> There were some questions on this list relating to
> exactly what the scalability issues wrt security are,
> and how costly it is to maintain large numbers of
> SAs etc. Maybe I can offer some thoughts on the
> subject from the point of view of an IPsec
> implementor (even on small systems):
> 
> * I'm pretty sure the IESG is talking about the
>   overhead in setting up the SAs, not e.g. the
>   overhead of IPsec AH itself. Why? See below...
> 
> * The header overhead per secured BU packet shouldn't
>   be a concern. There aren't enough BU packets to
>   make this significant.
> 
> * The cryptographic processing (e.g. MAC verification)
>   shouldn't be a concern either. Again, you won't be
>   doing all your traffic with these. And even if you
>   were - what do you demand: that you can have security
>   but not have to execute any cryptographic operations
>   at all? MAC verification must be one of the cheapest
>   cryptographic operations.
> 
If you piggyback Binding updates on an existing TCP connection
which accepts only clear packets, then the peer would drop
packets because the policy says "accept" clear packets". 
I don't know how many implementations latch the policy for
the duration of a TCP connection. We can solve this by
mandating that BUs should not be piggybacked.

> * Memory consumption. Well, essentially an SA needs
>   an SPI number (4 bytes), protocol (1 byte), secret
>   (e.g. 16 bytes), various algorithm etc indicators
>   (say 4 bytes), and maybe a couple of other things
>   such as sequence numbers. So, in conclusion you
>   could spend in the best case maybe some dozens
>   of bytes, typical implementations perhaps use
>   something in the order of a few hundred bytes
>   at the worst. (Adding encryption algorithm that
>   needs a large table to speed things up could
>   set you up for an additional few kilobytes.)
> 
>   Of course there also has to be some sort of
>   policy information that determines which
>   packet should be protected how, but I haven't
>   counted this as that sort of thing depends to
>   vary a lot between systems, and is in any
>   case the same for all possible security schemes.
> 
>   In conclusion, the memory consumption varies
>   as you use different length keys and different
>   algorithms, but isn't really that significant.
>   Think you need million SAs and claim that IPsec
>   AH doesn't scale in terms of memory needed? Well,
>   I'll use again my argument about the use of some
>   crypto at least. Otherwise you won't have security.
>   And if you have some cryptographic operations, do
>   you think you're going to survive without any
>   secrets or connection identifiers whatsover, or
>   sequence numbers? Don't think so. No security
>   costs less than security, but all security schemes
>   will require _some_ amount of storage.
> 
All the selectors defined in section 4.4.2 of RFC 2401 should
be there in the SA. These are needed for inbound selector
verification.

> * What about the overhead in setting up the SAs then?
>   Where are the concerns? (Don't you just love the
>   divine wisdom we are getting from the iesg, it
>   is very hard to decipher their input.)
> 
>   Here I think we see several issues. One, there
>   is again a number of cryptographic operations
>   which are very heavy this time: Diffie-Hellman,
>   RSA, ... Second, protocols to negotiate this
>   are complex. Third, how do we set up the trust
>   for the protocols to work, do we need a global
>   PKI?
> 
I don't think overhead is a real issue. Once an SA is setup,
it can be used for a lot of BUs.

-mohan

> *
> I firmly believe the trust part is the hard
>   one here. Almost everybody agrees that building
>   global PKIs is neither possible nor desirable.
>   I think this is what the IESG is worried about.
> 
> * Cryptographic operations for the set-up.
>   This is a hard one, too, particularly for
>   small systems. Before you decide that you
>   can't afford protocol X because it uses
>   algorithm Y which is heavy, please decide
>   what are the security requirements! If you
>   *can* compromise on Man-in-the-Middle protection,
>   for instance, then maybe something can be done.
>   Otherwise...
> 
> * Protocol complexity. Yeah. A lot of the
>   complexity comes from the PKI stuff, by the
>   way. Avoid that and you get rid of it...
>   Not avoid it and it won't help much if you
>   simplify your keying protocol or the packet
>   protection protocol... Also, when you consider
>   things like KINK in a global context you'll
>   propably have to do Kerberos *and* public
>   key schemes with PK-Init.
> 
> * I believe somebody mentioned also that IPsec
>   can't deal with the policies to protect
>   particular extension headers. I believe this
>   is an issue that could be dealth with, if
>   we wanted to.
> 
> Hope this helps,
> 
> Jari

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 27 Mar 2001 14:23:43 -0800

> it can be used for a lot of BUs.

The scenario mentioned by the IESG is a server with many 100,000s of
connections.  Here the overhead seems to be a show-stopper.

Which brings me to another thought.  Do we want different mechanisms for
different cases.  Talking to yahoo.com is completely different from talking
to my PC at home or my corporate VPN.  If I were sitting in starbucks
surfing the web with my PC over 802.11, I don't need any "mobility" at all
and no MITM protection if the 802.11 had individual encryption.  All I want
is to obtain a local IPv6 address...

Not sure one size fits all applies, though I have no idea what the practical
implications of the brilliantly pedantic observation are...

PF

---

From: Francis Dupont <[email-masked]>
Date: Sat, 31 Mar 2001 12:46:57 +0200

different cases.

=> I believe we need some kind of negotiation.

   Talking to yahoo.com is completely different from talking
   to my PC at home or my corporate VPN.

=> I agree: in the second case we have public/private key pairs and
not be able to use them would be silly.

=> two exchanges: the first one with cookies (DoS protection) and proposals,
the second one with the crypto stuff negociated in the first exchange.

Regards

[email-masked]