[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MAST and mip based solution
Dave,
> -----Mensaje original-----
> De: Dave Crocker [mailto:dcrocker@brandenburg.com]
> Enviado el: jueves, 18 de septiembre de 2003 22:55
> Para: marcelo bagnulo
> CC: Spencer Dawkins; multi6@ops.ietf.org; mbagnulo@ing.uc3m.es
> Asunto: Re: MAST and mip based solution
>
>
> marcelo,
>
> >> I think that MIP loses on all 3 counts. It requires modification
> >> to the user
> >> stacks, and requires enhancements to infrastructure software and
> >> operations.
> >>
>
>
> mb> You can argue that for instance MAST is much simpler (i
> choose mast just as
> mb> an example), but how simple will it be when you provide
> proper security
> mb> features. My guess is that it will be at least as complex as mip.
>
> It appears that one can specify adequate security without
> creating or using
> any infrastructure services. From my perspective, complexity and
> barriers to
> adoption primarily depend upon the number and placing of system
> components,
> rather than the specific algorithms that are used.
>
> MIP needs infrastructure. MAST does not.
>
Uh? Which infrasturcture does MIP needs to provide multi-homing?
>
>
> >> This is only my opinion, but I would expect we would get more
> >> simplification from dropping the requirement to support simultaneous
> >> movement at both ends than we would from relaxing security
>
>
> mb> actually i would be satisfied if we could build a solution to
> provide just
> mb> multi-homing support (i.e a solution for multi-homing without
> support for
> mb> mobility (note that this is the charter of this wg :-)), but
> i think that
> mb> this is also very hard with the current security requirements.
>
> As I discuss in the -choice- paper, it is increasingly looking to me as if
> multihoming and mobility can and should be viewed as two sides of the same
> topic. That's why I combined them under the term multiaddressing.
>
> Clearly one can separate them. But to either of them completely, you must
> include some features from the other.
>
Yes, that's why i think that we could apply mip stuff to multi-homing, but i
just wanted to point that if we find a multi-homing solution that solves all
the mh problems but that doesn't provides mobility support, i would find it
completelly acceptable.
>
> mb> So, i agree with you, simultaneous movement is really a plus plus...
>
> Even without mutual mobility. Simple initiator mobility (where
> the target is
> static) does not require the significant, extra functionality to support a
> mobile target. However even then mobility can encounter having
> the old and new
> addresses available at the same time. That sounds like multihoming.
>
>
> >> End-to-end MAST really could help us move to peer-to-peer applications
> >> in many, but not all, environments. MIP is certainly a more complete
> >> solution, and I'm not bashing MIP here, only suggesting that MAST may
> >> really have a role for multihoming support, without reducing security.
>
> mb> Here is where we disagree.
>
> Actually, I think you agree. I know _I_ agree with you (or
> rather, I disagree
> that we disagree...)
>
>
> and here's why:
>
> mb> I don´t think you can provide the current ipv4
> mb> level of security with mast if you don't use
> cryptographically generated
> mb> identifiers i.e. HIP.
>
> Correct. That's why the MAST proposal called for crypt-gen-id's:
>
> draft-crocker-mast-proposal-01.txt:
>
> 3.2. Association Attributes
>
> An MAST association is between a pair of hosts, defined by
> endpoint identifiers, an association label and a transaction
> sequence identifier.
>
> It comprises a domain name double, an Association Nonce double,
> and a transaction sequence number (TSN) double:
>
> Endpoint Globally unique, macro-labels
> identifiers: comprising a domain name for each host
>
> Endpoint Association nonce, with cryptographic
> association protection against hijacking. It is an
> label: internal identifier for the MAST
> association; it comprises a random
> value, such as defined in Section
> 6.4.2, "Connection Nonce Feature" and
> used in Section 6.4.3, "Identification
> Option", in [DCCP]. Also see [RAND].
>
> A critical question is where the cryptographic string comes from.
> I believe
> it is acceptable to have it be independently generated, so that it has
> statistical uniqueness, rather than guaranteed uniqueness.
>
>
> mb> But let's try to do it.
> mb> Let's try to define a security solution for MAST and see what
> happens (i am
> mb> willing to contribute)
>
> Thanks. My current guess is that PBK is plenty, although Erik
> Nordmark has
> suggested a simpler mechanism will suffice.
>
> The core of the algorithm seems to be to have each side generate
> a random --
> and therefore unguessable -- string and then do a hand-shake to reliably
> exchange it with the other side. The string is then presented in
> each message
> as a context (association) identifier.
>
> If more is needed, then what and why?
>
There is an important difference between hip and pbk, if i understand it
correctly, which is the following:
PBK allows you to be sure that once you have contacted the other end, it
will remain being the same, no matter if the ip address change
OTOH HIP allows to to be certain that the other end is who you want to
communicate with, even before you establish the communication.
This basically because in a pbk are transient identifiers, so host recognize
each other using ip addresses (after a while that they don't talk each
other) (for instance you don't store pbks in the DNS)
HI are permanent identifiers, so hosts recognize each others using hi
Example:
Today you identify the other end of a communication through an ip address.
This means that if i know i want to communicate with A, i have to know A's
ip address. Put it in another way, i use ip addresses to recognize host that
i already know.
PBK doesn't change this. So if I want to communicate with a certain ip
address IPA and i use PBK,
i establish the communication with IPA,
i make a DH excahnge to generate a shared key
and then we can both change our addresses and still be able to recognize
each other.
However, this doesn't prevent attacks where the attacker is trying to steal
your ip address.
Actually, using pbk enable address stealing shifted in time.
I mean, suppose i want to impersonate A. I establish a communication using
IPA
The other end recognizes me because i am using IPA
Then we start the pbk dh exchange (the attacker has to intercept these
packets)
Once the pbks are generated, the attacker can leave the place and use an
alternative ip address and he is recognized as being A because he has the
pbk.
If you use hip, hosts recognize each other through the HI. You cannot
pretend to own someone else' s hi because you won't be able to prove it (you
just don't have the private key that is required)
Regards, marcelo
>
>
>
> d/
> --
> Dave Crocker <dcrocker-at-brandenburg-dot-com>
> Brandenburg InternetWorking <www.brandenburg.com>
> Sunnyvale, CA USA <tel:+1.408.246.8253>
>