This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/nextepc@lists.osmocom.org/.
Sukchan Lee acetcom at gmail.comHi Harald,
For the most part, you need to see the UNION definitions in
src/mme/mme_context.h as below.
348 union {
349 struct {
350 ED3(uint8_t spare;,
351 uint16_t overflow;,
352 uint8_t sqn;)
353 } __attribute__ ((packed));
354 uint32_t i32;
355 } ul_count;
Therefore, increasing SQN will also increase ul_count.i32.
Let me add the comments in src/mme/nas_security.c
/* If SQN exeeds 1 bytes and turn in once again,
Overflow is increased */
197 if (mme_ue->ul_count.sqn > h->sequence_number)
198 mme_ue->ul_count.overflow++;
/* Always set SQN from UE's SQN as below */
199 mme_ue->ul_count.sqn = h->sequence_number;
Let me know if I have misunderstood anything.
Thanks a lot!
Best Regards,
Sukchan
On Sat, Jul 13, 2019 at 10:19 PM Harald Welte <laforge at gnumonks.org> wrote:
> Hi Sukchan and list,
>
> I'm currently reading the MME code and I'm having some trouble
> understanding
> the handling of the uplink counter for NAS security.
>
> I only see mme_ue->ul_count.i32 ever being set to '0' when a new security
> context is used. But I don't see it ever being incremented? I only see
> ul_count.sqn incremented, but then the nas_mac_calculate() always gets
> ul_count.i32 passed as input.
>
> So I'm somehow not understanding how the MAC can ever verify on any uplink
> message beyond/after the first one which establishes a new security
> context.
>
> What am I missing? Thanks for your insight!
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
> (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190714/7b61647c/attachment.htm>