Re: flow label demultiplexing

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 18/04/2005, a las 16:52, Pekka Savola escribió:

> On Mon, 18 Apr 2005, marcelo bagnulo braun wrote:
> > > First, one specific comment:
> > >    An added limitation imposed by this approach is that all the
> > >    potential source and destination locators have to be known 
> > > beforehand
> > >    by the receiver in order to be recognized.
> > > ==> I don't understand why this is a limitation in practice (though 
> > > it may be an architectural limitation).  Isn't the assumption that 
> > > all the potential locators must be exchanged somehow before the 
> > > network connectivity failure, otherwise the shim6 solution might not 
> > > be able to switch to working locators?  Otherwise the rehoming could 
> > > not be secured...
> >
> > Well, if you are using CGA security, you could use the new locator 
> > (as source address) without prior information to the peer. This could 
> > be useful in *some* scenarios (let's not mention the word for now :-)
> > CGA  based security does not need prior exchange of locators, right?
>
> Sorry, I don't quite follow.  Based on my reading of the HBA spec (I 
> was more confused when I read the new version, because I had thought 
> it worked differently)..

> Is it true that you can use CGA or HBA addresses for connection 
> survivability only after you have used the shim6 protocol to pass the 
> Parameter Data Structure, right?

right. but in the HBA case, the CGA parameter data structure contains 
the available prefixes, but in the CGA case, it contains the public 
key, agree?

>   Otherwise I'm not sure how the host could verify the HBA address 
> (i.e., how is step 1 of Section 5 accomplished otherwise?).
>
> Note that HBA+CGA in one doesn't help (AFAICS) because otherwise you'd 
> be trusting anyone you have a public key with to not hijack any of 
> your sessions?

Well, i guess not.

In the CGA case, the address being used as the ULID for the 
communication is a CGA that contains a hash of the publich key in the 
iid. In this case, you will only trust a public key whose hash matches 
the iid of the ulid.

So, when you use CGA capabilities of the address, the CGA parameter 
data structure is exchanged upfront and it contains the public key.

Next, the node can use a new address (that was not included in the CGA 
parameter data structure) because it can authorize it by signing it 
with the private key corresponding to the CGA. Moreover, such signature 
could even be included in a packet that contains the new address as 
source address (i think)

I mean, with CGA there is no need to know the addresses before hand.

Make sense?

regards, marcelo


> Or were you talking about the case where the host obtained a new 
> source locator and wants to start using it immediately, and send the 
> first packet using shim6 protocol (also using the new locator as 
> source),  i.e., "piggybacking"?  That would likely need more than just 
> a flow label in any case, so I don't see how that would apply.
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings