[TEST] Add state machine

[Raguideau]

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

• I have read the CONTRIBUTING document.
• Each of my commits messages include Signed-off-by: Author Name <[email protected]> to accept the DCO.

[linouxis9]

Thanks a lot for your PR!

A suggestion: if we're going to do things properly, we should do them this way:

• Instead of having the stateMachine in a hook, it should become an integral part of the aio5gc's UEState, which would make it possible to properly implement the transition
  RegistrationRequest -> AuthReq and
  RegistrationRequest -> RegistrationAcccept depending on current status, for example.
  And if AuthReject, we start again from the beginning etc... basically allowing us to validate the whole call flow.
• And then, we modify the hook system so that we can insert a hook at each transition (eg. in the callbacks) rather than as we do at present, as the whole point of having a stateMachine with transitions was to check the correct flow of messages, which might be different in each test.

Make sure to accept DCO as well.

[linouxis9]

Thanks for the new commit!
It's not exactly what we should do.
The state machine should be intrinsic to the aio5gc, it should not be set by the tests.
The whole point of having a state machine in aio5gc is that you don't have to do things like this:

	if !ue.GetInitialContextSetup() {
		return errors.New("[5GC][NGAP] This UE has no security context set up")
	}
	if ue != ranUe {
		return errors.New("[5GC][NGAP] RanUeNgapId does not match the one registred for this UE")
	}

Basically, the point is that you have one handler per state (eg. the callback).
You don't need to do these kinds of checks:
In the Registered state handler, you can handle a Session Establishment PDU, and a Deregister.
However, it won't be possible in the fresh state handler.
And then we can have hooks in each of these handlers (using a map msg.MsgType -> hook and call it generically from each callbacks.)

Note that you can have several PDU Sessions, so you'll need a global state machine + one per PDU Session (this is what's normally done in the AMF for the 5GMM state machine the SMF for the 5GSM state machine per PDU Session).

This is something we would also need to implement on PacketRusher's side instead of our current big global handler.

See for reference: 24.501 Figure 5.1.3.2.1.1.1: 5GMM main states in the UE:

https://www.tech-invite.com/3m24/toc/tinv-3gpp-24-501_l.html

And 24.501 Figure 6.1.3.2.1.1: The 5GSM sublayer states for PDU session handling in the UE:

https://www.tech-invite.com/3m24/toc/tinv-3gpp-24-501_zg.html

[linouxis9]

You should use your state machine instead of doing this kind of check. You should have a branch of states where you are sure that securityContext is available. The goal of having a state machine is that when you arrive to a given state, you are sure that some preconditions are valid, here that the SecurityContext is available.
Then you have an Encode for state SecurityContextAvailable and an when it is not the case. Same for Decode.

[linouxis9]

Thanks a lot for your work!
Make sure to sign DCO for the previous commits as well
See the commands at: https://github.com/HewlettPackard/PacketRusher/pull/63/checks?check_run_id=20501740969

[linouxis9]

Cool! Make sure that nasEncoder changes depending the states to avoid all these checks a bit everywhere
Same for decoder, you should not allow a non-integrity protected message after auth.
Don't forget about DCO on previous commits, no FSM global, and previous comments as well :-)
Thanks a lot!

[linouxis9]

We have the same code in the core PacketRusher code, could it be factorized?

[linouxis9]

This comment again

[linouxis9]

This comment again

[linouxis9]

Can it be factorized with PacketRusher?

[Raguideau]

yes, we should also be able to factorize authentication. I will do it in another pr.