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

RE: Reasonable to use crypto in all communications? (Re: Fwd: Minutes/ Notes)




> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Pekka Nikander
> Enviado el: jueves, 24 de julio de 2003 14:46
> Para: marcelo bagnulo
> CC: Masataka Ohta; multi6@ops.ietf.org
> Asunto: Reasonable to use crypto in all communications? (Re: Fwd:
> Minutes/ Notes)
>
>
> > So i guess that my question would be: is it a reasonable approach to use
> > crypto in all comunications? (such as HIP)
>
> I don't think so.  There certainly is some communication that
> does not need any protection at all in addition to what is
> provided by the application layer.
>
> On the other hand, it has been stated that there certainly is
> some communication that does not need the added flexibility and
> robustness provided by the id/loc separation.
>
> Now, there is a good question:  Do we get four distinct subsets,
> each of a reasonably big size, or is any of the four subsets
> so small that we can almost ignore it:
>
>    - non-robust, non-flexible, non-protected traffic (current IP)
>    - non-robust, non-flexible, protected traffic (current IPsec?)
>    - maybe-multihomed, maybe-mobile, non-protected traffic
>    - maybe-multihomed, maybe-mobile, protected traffic

I would say that none of those 4 types can be negliged.

>
> The id/loc mapping itself needs some kind of protection, or otherwise
> we get new nasty DDoS attacks using all hosts, even uncompromized
> ones, as zombies.  The actual traffic may or may not need protection.
> It is a know deficiency in the current HIP spec that it does not
> directly support non-protected traffic.  However, if unencrypted,
> non-integrity protected ESP was allowed, one could use the SPI
> in the ESP header as a kind of condensed identifier, without
> any cryptographic protection.
>

I am not so sure.
I would say that inlcuding unprotected identifiers instead of unprotected
locators is weaker, since locators are somehow verified by the routing
system and ingress filtering and identifiers (as currenlty proposed) are not
verified. I mean, it would be trivial to impersonate an identifier, since
the packet would be routed using the locator (this is not the case if
locator and identifier are the same). Am i missing something?

marcelo

> --Pekka Nikander
>
>
>