From pshinjo at sec.t-labs.tu-berlin.de  Thu Nov 16 14:54:15 2017
From: pshinjo at sec.t-labs.tu-berlin.de (Shinjo Park)
Date: Thu, 16 Nov 2017 15:54:15 +0100
Subject: RFC: new type for NAS/EPS in gsmtap.h and question
Message-ID: <1676633.vrP4Qaqq7O@brandenburg>

Hi list,

While I was experimenting with osmo-qcdiag and other LTE stuff, I want to add 
NAS/EPS as a new payload type for gsmtap.h.

Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and 
RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS 
security had been activated only encrypted NAS messages are available at RRC 
layer. This is reflected into the baseband diagnostics of various makers: 
Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and 
plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this 
issue. I can submit a patch if this looks positive.

Also, I have a question regarding ARFCN field. Currently (in version 2) ARFCN 
is a 16-bit integer, with 2-bit of flags (PCS band, uplink) therefore making 
14-bits available for raw value. This causes some problem in LTE:

1) EARFCNs for uplink are starting from 18000, which is larger than 2^14
2) There are EARFCNs even larger than 2^16 (Bands 65+, LTE-U frequencies)
3) No separate indicator for ARFCNs used by UMTS/LTE-TDD network

Also in UMTS, there are overlapping UARFCNs between bands, which necessitates 
a separate field for band indicator. Changes regarding these will break the 
GSMTAP header structure, therefore I want to discuss about how these could be 
addressed.

Best Regards,
Shinjo
-- 
Shinjo Park <pshinjo at sec.t-labs.tu-berlin.de>
Security in Telecommunications <sec.t-labs.tu-berlin.de>
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
Phone: +49 30 8353 58272


From laforge at gnumonks.org  Thu Nov 23 17:13:05 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 23 Nov 2017 18:13:05 +0100
Subject: RFC: new type for NAS/EPS in gsmtap.h and question
In-Reply-To: <1676633.vrP4Qaqq7O@brandenburg>
References: <1676633.vrP4Qaqq7O@brandenburg>
Message-ID: <20171123171305.rixhd75agp7k4cpe@nataraja>

Hi Shinjo,

On Thu, Nov 16, 2017 at 03:54:15PM +0100, Shinjo Park wrote:
> While I was experimenting with osmo-qcdiag and other LTE stuff, I want to add 
> NAS/EPS as a new payload type for gsmtap.h.

perfectly fine.

> Unlike GSM and UMTS, LTE introduced separate layer for encryption of NAS and 
> RRC. As a result, while NAS messages are piggybacked to LTE RRC, but after NAS 
> security had been activated only encrypted NAS messages are available at RRC 
> layer. This is reflected into the baseband diagnostics of various makers: 
> Qualcomm provides separate diagnostic item for LTE NAS (both encrypted and 
> plain) and RRC. Separate payload type for LTE RRC and LTE NAS will solve this 
> issue. I can submit a patch if this looks positive.

Yes, please send a patch both for the gsmtap header file in libosmocore as well
as for the wireshark dissector.

> Also, I have a question regarding ARFCN field. Currently (in version 2) ARFCN 
> is a 16-bit integer, with 2-bit of flags (PCS band, uplink) therefore making 
> 14-bits available for raw value. This causes some problem in LTE:

Well, the field was really intended for GSM ARFCN, and not for UARFCN or EARFCN.

All of GSMTAP was intended for GSM, everything else was just a rather dirty
addition.

> 1) EARFCNs for uplink are starting from 18000, which is larger than 2^14
> 2) There are EARFCNs even larger than 2^16 (Bands 65+, LTE-U frequencies)
> 3) No separate indicator for ARFCNs used by UMTS/LTE-TDD network

ACK.

> Also in UMTS, there are overlapping UARFCNs between bands, which necessitates 
> a separate field for band indicator. 

ACK.

> Changes regarding these will break the GSMTAP header structure,
> therefore I want to discuss about how these could be addressed.

Basically, we'll need a new version of the header, and then have a
dissector for both the old and the new format.  UMTS/LTE applications
that care about U/EARFCN can then make use of the new header version
while existing legacy programs continue to use the old format.

The new common header should be much shorter.  It shouldn't even contain
fields like timeslot / subslot that don't make sense on non-TDMA
systems.  Even ARFCN could be removed and, and then be part of a
type-specific 'next header' or 'option header'.

so something like

struct gsmtap_v3_header {
	uint8_t version;
	uint8_t hdr_len;
	uint8_t type;
	uint8_t antenna_nr;

	int8_t signal_dbm;
	int8_t snr_db;
	uint8_t sub_type;
	uint8_t res;	/* or maybe expand sub_type to 16bits? */
};

followed by

struct gsmtap_opt_hdr_gsm {
	uint16_t arfcn;
	uint8_t timeslot;
	uint8_t sub_slot;
};

struct gsmtap_opt_hdr_umts {
	uint32_t uarfcn;
	uint8_t band;
	...
};

struct gsmtap_opt_hdr_lte {
	uint32_t earfcn;
	...
};

seems like a good idea to me.
-- 
- 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)


From pshinjo at sec.t-labs.tu-berlin.de  Mon Nov 27 10:11:58 2017
From: pshinjo at sec.t-labs.tu-berlin.de (Shinjo Park)
Date: Mon, 27 Nov 2017 11:11:58 +0100
Subject: RFC: new type for NAS/EPS in gsmtap.h and question
In-Reply-To: <20171123213447.jgumhjpkxn3g7j2v@nataraja>
References: <1676633.vrP4Qaqq7O@brandenburg>
 <BDA5E7F9-C0B3-4773-82E1-E55D16B2E437@imag.fr>
 <20171123213447.jgumhjpkxn3g7j2v@nataraja>
Message-ID: <9393420.BgeNa6r4Vq@brandenburg>

2017? 11? 23? ??? ?? 10? 34? 47? CET? Harald Welte ?? ? ?:
> On Thu, Nov 23, 2017 at 09:47:25PM +0100, Martin Heusse wrote:
> > Harald, Shinjo,
> > please find below is a tiny patch to add
> > #define GSMTAP_TYPE_LTE_NAS		0x12
> > to packet-gsmtap.h
> > and the corresponding code that uses it.
> 
> great, feel free to push this to the wireshark gerrit.
> 
> I've made a corresponding change in libosmocore, see
> https://gerrit.osmocom.org/5018
> 

Forwarding the discussion at Wireshark gerrit at https://code.wireshark.org/
review/#/c/24554/4:

Devices dumping NAS messages can give both encrypted and plain messages. At 
least for Qualcomm LTE basebands it is true. Therefore using sub_type for 
differentiating encrypted and plain NAS messages were discussed there. This 
will likely introduce another modifications to gsmtap.h, and therefore want to 
discuss more about this topic also here.

Shinjo

-- 
Shinjo Park <pshinjo at sec.t-labs.tu-berlin.de>
Security in Telecommunications <sec.t-labs.tu-berlin.de>
TU Berlin / Telekom Innovation Laboratories
Ernst-Reuter-Platz 7, Sekr TEL 17 / D - 10587 Berlin, Germany
Phone: +49 30 8353 58272