[Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>]

On Sun, Jan 4, 2015 at 1:32 AM, Luke Mewburn <luke@xxxxxxxxxxx> wrote:

Hi all.

I've observed that Wireshark's TCAP session (transaction) matching
(enabled with tcap.srt:TRUE) doesn't operate correctly in various cases.

I've been working on improving Wireshark's TCAP session handling,
and have some questions about the "best" way to do this as a new
contributor to the Wireshark development community.

I'm not sure if it's preferable to describe all of the issues
in one 'wall of text' email or split up the discussions across
multiple messages; I've gone with the former :)

Please let me know if the issues should be split out into separate
discussions, or if there's a better forum for this (e.g. bugzilla
tickets).

regards,
Luke.


Specific fixes
--------------

1. SCCP GT not set if route-on-SSN.

DETAILS:: When sccp.set_addresses is TRUE, the GT isn't used if present
when the SCCP route-on-SSN bit is set (i.e not route-on-GT).
The GT is still useful for TCAP matching even in this case.

PROPOSAL: I've submitted a change for this at:
        https://code.wireshark.org/review/#/c/6053/
(The second patch attempt is a minor improvement to the wording
of the preference after the changes in the original patch).


2. TCAP session matching incomplete.

DETAILS: TCAP session matching doesn't cope with TCAP dialogue
confirmation. (See "TCAP background" below for more information
about dialogue confirmation).

This is because the current implementation uses the destination
address for TCAP BEGIN matching (tcaphash_begin_info_key_t.dpc_hash),
and origin address for TCAP END matching
(tcaphash_end_info_key_t.opc_hash).

When TCAP sessions (transactions) aren't correctly matched,
then higher level dissectors can mistakenly decode packets
part-way through the session because of assumptions about
protocol versions (etc). There are existing Wireshark
bugs in TCAP (and higher layer) that may be fixed by addressing this

PROPOSAL: I have some changes to be submitted for review which
resolves this, and greatly improves transaction matching when
sccp.set_addresses:TRUE and tcap.srt:TRUE, even when the destination
address of the TCAP BEGIN changes as part of dialogue (transaction)
confirmation.


Future proposals
----------------

(These could be moved into separate discussions).

1. SCCP addresses not set by default.

DETAILS: By default, the SCCP GT is not set as the source and destination
addresses for higher layer protocols. The MTP3 (or M3UA) point codes
(PCs) are left as these addresses.
This can be changed with the preference option sccp.set_addresses.
For TCAP transaction matching, the SCCP GT is more correct than the
MTP3 PC.

PROPOSAL: The sccp.set_addresses default could change to TRUE (and
possibly the SUA equivalent, although I haven't any experience with
SUA), but I'm not sure what ramifications that this has on protocols
other than TCAP that use SCCP.


2. TCAP filters for party addresses.

DETAILS: I've experimented with adding new filter nodes to contain the
(SCCP GT) addresses of the original calling party (from TCAP BEGIN),
the original called party (from TCAP BEGIN), and the confirmed party
(from first TCAP CONTINUE or END-after-BEGIN).

These depend upon the SCCP addresses set (see above) and
the session matching fixed.

PROPOSAL: Add new filters.  I have a work in progress for this
which could be submitted for review.


3. TCAP session matching not enabled by default.

DETAILS: The session matching isn't enabled by default.
I suspect that this is because it has a performance impact
and that it doesn't work reliably (without my fixes :).

PROPOSAL: Once the session matching is fixed, it could be
enabled by default.


4. TCAP converted to conversation.h (after the latter is enhanced)

DETAILS: TCAP uses its own session matching logic.  If the standard
"conversation.h" implementation was used, then there may be other
benefits such as following conversation flows.

I've experimented with this in a private branch, but ran into issues in
the current conversation.h implementation that need to be addressed
for TCAP.

I implemented a new port type - PT_TCAP - to contain the TCAP
transaction ID (TID).

As described below in "TCAP background":

- TCAP BEGIN contains a src addr, otid (src port), and dst addr.
  The dst addr may change in the first CONTINUE.

  We have to create the conversation with NO_ADDR2 as well as NO_PORT2,
  which results in the conversation added to
  conversation_hashtable_no_addr2_or_port2.

- TCAP CONTINUE contains src addr, otid, dst addr, dtid.

  Looking this up with find_conversation() seems to work;
  if it's the first CONTINUE the conversation is moved from
  conversation_hashtable_no_addr2_or_port2 to
  conversation_hashtable_exact.

- TCAP END & ABORT contains the dst addr, dtid (dst port), and src addr
  without src port (otid).
  The dst addr may change in the first CONTINUE or an END after BEGIN.

  If the TCAP END is after a BEGIN, the conversation may be found
  from conversation_hashtable_no_addr2_or_port2 if the addresses are
  swapped, but if a TCAP CONTINUE is part of the transaction the
  conversation will have been moved to conversation_hashtable_exact
  and thus can't be found without the src port.

PROPOSAL: Further investigation and discussion is required about how
to enhance conversation.h to resolve this.
I suspect we need special-case handling in find_conversation() (etc)
for PT_TCAP, including possibly a separate hashtable or keeping
the TCAP BEGIN in the conversation_hashtable_no_addr2_or_port2 in
parallel to the entry in conversation_hashtable_exact.


5. Passing sccp_msg_info_t to child dissectors.

DETAILS: sccp only passes the sccp_msg_info_t to child dissectors
if SCCP tracing is enabled and there's an SCCP association (i.e.
SCCP connection-based protocols).

It could be useful to provide the sccp_msg_info_t sccp_msg member
of sccp_decode_context_t to TCAP (and possibly other connectionless)
dissectors so they can obtain SCCP addressing directly.

I'm still experimenting with this.


TCAP background
---------------

TCAP (as described in ITU-T Q.771 (06/97) (et al)) uses SCCP for
addressing when used in SS7 networks.
Q.771 mentions that further study is required if other (non-SCCP)
networks are to be used; I'm not aware if any are.

TCAP supports transactions (between two peers) with a structured
dialogue with transaction IDs, with each peer using its own
transaction ID, with TCAP messages BEGIN, CONTINUE, END, ABORT.

TCAP uses originating and destination address from SCCP;
the SCCP calling party is the origination address,
the SCCP called party is the destination address.

TCAP BEGIN has an originating transaction ID (OTID).
TCAP END & ABORT has a destination transaction ID (DTID).
TCAP CONTINUE has both an OTID and DTID.

Common TCAP transaction patterns include:

(1)     TCAP BEGIN      orig=A otid=At  -> dest=B
        TCAP END        orig=B          -> dest=A dtid=At

(2)     TCAP BEGIN      orig=A otid=At  -> dest=B
        TCAP CONTINUE   orig=B otid=Bt  -> dest=A dtid=At
        TCAP CONTINUE   orig=A otid=At  -> dest=B dtid=Bt
        TCAP END        orig=B          -> dest=A dtid=At

Note that the END (or ABORT) doesn't contain the otid.


TCAP also supports the concept of "dialogue confirmation" -
see Q.771 clause 3.1.2.2.2.2 "Confirmation of the dialogue".
This means that the first CONTINUE in a transaction can change
the orig address.  The pattern for this can be:

(3)     TCAP BEGIN      orig=A otid=At  -> dest=B
        TCAP CONTINUE   orig=B2 otid=Bt -> dest=A dtid=At
        TCAP CONTINUE   orig=A otid=At  -> dest=B2 dtid=Bt
        TCAP END        orig=B2         -> dest=A dtid=At
The BEGIN was to dest=B, the first CONTINUE was orig=B2.

In practice, a transaction consisting of BEGIN then END (pattern (1)
above) can also do this in the END.

The better is create a bug in bugtracker with subject like : Enhance TCAP dissector (and list the list of issue/change)

and push your patch on gerrit with in commit log the reference to this bug (Ping-Bug: XXXX)

Also attach in bug, some pcap sample for try.

Regards,

 

--

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe