fix(mme): [S1 handover] fix bugs in security context for HandoverRequest Msg#7985
fix(mme): [S1 handover] fix bugs in security context for HandoverRequest Msg#7985ulaskozat merged 1 commit intomagma:masterfrom
Conversation
|
Thanks for opening a PR! 💯 Please note that all commits must be signed off. This is enforced by the Howto
More infoPlease take a moment to read through the Magma project's
If this is your first Magma PR, also consider reading
|
|
|
||
| /* TODO: investigate | ||
| 1- Should we bump next_hop and use it in this message (as is) | ||
| 2- or, use the previously calculated next_hop and bump up for next | ||
| iteration. In this case, we are missing a bump to next_hop someewhere | ||
| else, per testing | ||
| */ |
There was a problem hiding this comment.
TL;DR We should bump up next_hop and ncc, store these new values and send them to target eNB in S1 Handover Request.
Longer explanation:
https://www.etsi.org/deliver/etsi_ts/133400_133499/133401/15.07.00_60/ts_133401v150700p.pdf section 7.2.8.4.3 indicates that (source and target MMEs in this case are the same):
- "Upon reception of the HANDOVER REQUIRED message the source MME shall increase its locally kept NCC value
by one and compute a fresh NH from its stored data" - "The source MME shall store that fresh pair and send it to the target MME in the S10 FORWARD RELOCATION REQUEST message." (here S10 can be ignored as source and target MMEs are the same.
- "The target MME shall store locally the {NH, NCC} pair received from the source MME.The target MME shall then send the received {NH, NCC} pair to the target eNB within the S1 HANDOVER REQUEST."
ulaskozat
left a comment
There was a problem hiding this comment.
I think bump up behavior is correct as noted in my comment.
…t msg Signed-off-by: Tariq Al-Khasib <[email protected]>
|
@talkhasib Why is the context release command is going to enb with ip ending 245 but not to enab with 249 (the requester)? |
ulaskozat
left a comment
There was a problem hiding this comment.
Context release is ending up at the wrong eNB?
Good catch I think these issues need to be addressed in a separate PR |
|
Thank you for finally finding the fix for this. :-) |
Okay, then let me stamp it again and you can merge it. I assume you did run the integ tests on this locally? |
ulaskozat
left a comment
There was a problem hiding this comment.
LGTM. The remaining issues will be handled in a separate PR.
…t msg (magma#7985) Signed-off-by: Tariq Al-Khasib <[email protected]> Signed-off-by: Oriol Batalla <[email protected]>
…t msg (magma#7985) Signed-off-by: Tariq Al-Khasib <[email protected]>
…t msg (magma#7985) Signed-off-by: Tariq Al-Khasib <[email protected]> Signed-off-by: Ramon Melero <[email protected]>
…t msg (magma#7985) Signed-off-by: Tariq Al-Khasib <[email protected]>
…t msg (#7985) (#8461) Signed-off-by: Tariq Al-Khasib <[email protected]> Co-authored-by: Tariq Al-Khasib <[email protected]>
…t msg (magma#7985) Signed-off-by: Tariq Al-Khasib <[email protected]>
Signed-off-by: Tariq Al-Khasib [email protected]
Summary
Security context next hop info were not properly computed or populated for HandoverRequest Msg. This PR resolves the following issues
1- A copy of emm_context was used to update next_hop and nhcc. These changes did not persist
2- We only copied 1 byte of the next_hop vector into the security context ie
3- We needed to bump the NHCC and next_hop before we copied into security context
The last point above needs investigation as noted with a comment on the code. We are either missing a bump to NHCC and next_hop somewhere else. Or this is the correct behaviour
Another place that needs investigation is the path switch msg for X2 handover as it populates a similar security context.
Test Plan
Tested on local setup with 2 baicells eNBs and a pixel3 phone
pcap is attached
S1HO_UE_Baicells.pcap.zip