| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I thought if the MSS and BS would like to skip PKM,
transferred security context(SAID, SA Type, Cyphersuite) is
meaningless without SAID remapping in some case. Otherwise, MSS and BS has to
renegotiate PKM again, but it's not what we intend to do with our efforts of HO
Optimization flags. I mean transferred security context has SAID, SA Type,
Cyphersuite. So we can think of some cases.
Case 1) Target BS can support cyphersuite, SA Type AND all
SAID's are the same as Serving BS.
->Just HO Optimization Flags is enough
Case 2) Target BS can support cyphersuite, SA Type BUT at
least one of SAID is different with the Serving BS.
->Just HO Optimization Flags is NOT enough, and SAID should be updated or
remapped by the Target BS and Target BS sends SAID_update
in RNG_RSP with the HO Optimization Flags Case 3) Target BS can NOT support cyphersuite and SA Type
and SAID is different with the Serving BS.
-> Target BS has enough knowledge about MSS capability, so target BS
make MSS change cyphersuite
to the one which both MSS and Target BS supports
In this case, two solutions can be conceived.
1)
Make MSS renegotiate whole PKM(I prefer to use this one, that's why I did
not put SA Descriptor but SAID.)
2) Make MSS use SAID and SA Type with different cyphersuite
In a nutshell, if the SAID is different then SAID_update
should be sent with RNG-REQ, unless BS does not want to renegotiate PKM with
MSS.
But summarizing the comments of below 3 friends, SAID_update
should be sent with CID_update in RNG-RSP. Junhyuk and Sungcheol mentioned
putting cyphersuite and change SAID_update into SA_Descriptor_update.
So what do you think about this? 1) Put SAID_update in RNG-RSP
or REG-RSP 2) SAID_update or SA-Descriptor_update
I'd like to incorporate your opinions into the revised
document until AOE 7 Jul. So I'll be expecting your opinions.
Thanks.
******************************************************************************************************************************************
[Phil] This is the SAID_Update component, excised from
C80216e-04/50r1, and presented here by itself, without all of the rest of the
16e-04/50r1 items, and changes to its application. Changed to apply
SAID_Update to RNG-RSP. Very bad. Should continue to apply it to
REG-RSP, just like CID_Update. It can still show up in RNG-RSP along with
the other SBC-RSP and REG-RSP in optimized HO, if that is what the implementor
intends. But it MUST be put with CID_Update, as originally intended.
Phil
[Vladimir]SA is not only SAID but also certain state machine that keeps control of AKs, TEKs etc. So we have to define how this context is transferred between BSs and how MSS resynchronizes with newely created SA at target BS [the synch might be lost during HO]. Transferring of new SAID is the least problem Vladimir [Jeff]The SAID update needs to be done indeed, but we can use the existing mechanism for changing SF parameters. That is to say, the new SAID can be included as a "changed parameter" together with the CID_Update, just like any other changed Service Flow parameter. Could the problem be solved by including the "Target SAID" TLV as one of the "changed parameters" in the CID_Update compound TLV? ie. the SAID can be updated together with other parameters of the connection that need to change, and the old SAID would not be needed. ================================== Donnie Dongkie Lee Seorindong 99, JongRoGu Seoul, Korea SK Telecom Phone: +82-2-6323-3147 Mobile: +82-11-758-4359 E-Mail: galahad@nate.com galahad@netsgo.com ================================== |