LPP heuristic

[wgreenberg]

Prerequisites

• I have read CONTRIBUTING.md

What problem does this feature solve or what does it enhance?

User jamyla posted on the community mattermost about an IMSI catcher that uses LPP to track UE location. Reporting LPP messages has been previously suggested in #534, but as far as I know nobody's tried it out. This seems like an interesting heuristic to add, even if only in an informational (as opposed to a warning) capacity.

Proposed Solution

Implement an informational heuristic that tracks LTE LPP messages, both the request and the response.

Alternatives Considered

No response

[wgreenberg]

i haven't looked too deeply into where LPP messages live in the telcom stack, but i did find this message type in the NAS parser: https://github.com/EFForg/pycrate-rs/blob/main/src/nas/generated/emm/emmdl_generic_nas_transport.rs

[philgebhardt]

Hey I'm interested in contributing here. After some looking around, I see a couple options:

A: a stateless set of heuristics that each watch for the flag on EMM{D,U}LGenericNASTransport, providing basic awareness that a LTEPositioningProtocolLPPMessageContainer was seen

• requires no new asn
• requests and responses are emitted separately

B: a heuristic that pairs a request with its response, using LPP-Message and LPP-TransactionID

• telecom-parser needs LPP asn definitions
• we can used parsed transactionID to detect pairs

I would like to go B if it sounds reasonable.

[wgreenberg]

@philgebhardt that'd be great! which layer of the stack are LPP-Message/LPP-TransactionID in? i'm not seeing them in RRC, but i might not be digging in the right place

[philgebhardt]

Hey @wgreenberg, it looks like it's at TS 37.355

https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=79309

[philgebhardt]

Hey @wgreenberg. After playing around with this, I've gotten to a point where I should share the progress I've made to make sure this is going in a direction that feels right. With scope of keeping these Informational only, the key thing I realized is that this heuristic can provide useful tracing info that could inform more targeted heuristics downstream. I tried to model the event output accordingly but I expect it will need some further tuning.

I've staged two draft changes

1. lte_lpp: telcom-parser: genreate ASN.1 & rust bindings #1142: the generated ASN.1 and rust bindings

• I ran into a small hiccup with using hampi to parse the spec and produce the bindings. Nothing crucial, but I outlined by generation steps in the commits that show the provenance of the generated material.

2. philgebhardt@00dccb6 a draft of the analyzer that tracks the lifecycle of LPP messages. I have not created a PR against rayhunter here as it depends on the first change.

Anyway, just wanted to share this progress and invite feedback. I'm now thinking about what it looks like to test this properly. I also have no idea how hard it is to capture a real LPP event stream if I were to load a build of this branch onto my own orbic. I'm definitely curious.

Thanks!

edit: re-pushed up a minor fix to item #2 above