Project

General

Profile

Actions

Bug #5208

open

ns2: add testcase for SNS Size with invalid tlv

Added by lynxis over 1 year ago. Updated 7 days ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
libosmogb
Target version:
-
Start date:
08/06/2021
Due date:
% Done:

90%

Spec Reference:
TS 148 016 V16.0.0
Tags:
Actions #1

Updated by laforge 4 months ago

  • Status changed from New to Feedback
  • Assignee set to lynxis

lynxis, are you thinking about a TTCN-3 testcase or a unit test in the libosmogb repo?

I think this could be something for arehbein to look into, but if its TTCN-3 somebody would likely have to help setting up the entire infrastructure, ..

Actions #2

Updated by laforge 4 months ago

  • Tags set to simple
Actions #3

Updated by lynxis 4 months ago

  • Assignee changed from lynxis to laforge

laforge wrote in #note-1:

lynxis, are you thinking about a TTCN-3 testcase or a unit test in the libosmogb repo?

I think this could be something for arehbein to look into, but if its TTCN-3 somebody would likely have to help setting up the entire infrastructure, ..

I would have implemented it as ttcn3 test case. But both are fine. I don't think ttcn3 is so hard to setup. You can run it locally without docker.

Actions #4

Updated by arehbein 3 months ago

  • Spec Reference set to TS 148 016 V16.0.0

lynxis Just to make sure I'm not misunderstanding anything here: This test is about the TLV only, i.e. the NSEI IE?
The description is a bit short, so for now I'm assuming it's basically about testing different kinds of erroneous NSEI IEs inside the SNS size PDU and expecting to get SNS size acks with corresponding 'cause' fields.
Please tell me if that is correct.

Actions #5

Updated by laforge 3 months ago

  • Assignee changed from laforge to lynxis

not sure why this is assigned to me if arehbein is working on it and it's waitiing for lynxis' feedback :P

Actions #6

Updated by laforge 3 months ago

I'm not the one who filed this issue, so I can only guess what lynxis might have meant. However, I don't understand why arehbein would mean an invalid SNS-SIZE would only be able to have a wrong NSEI IE?

The SNS-SIZE IE has all kinds of IEs, some mandatory and some optional. Beyond NSEI there's RESET_FLAG, MAX_NR_NSVC, IPv4_EP_NR, IPV6_EP_NR, see Section 9.3.7 of TS 48.016.

A wrong NSEI is more like a general failure. There's a NSEI in most if not all NS messages, and unknown/invalid NSEI is something that we handle in some generic code looking up the NSEI. I would think particularly critical is missing IEs such as IPv4/IPv6 endpoint number. For example, neither of the two is always illegal. Only one of v4/v6 in a situation where we expect the other might be another situation (think of one side being v4-only while the other is v6-only).

Actions #7

Updated by arehbein 3 months ago

laforge alright thank you. The NSEI is the only TLV of an SNS Size PDU, the others are TVs according to the spec. So I was wondering if there was anything particular to lookout for (and it didn't seem like it, as you said, the NSEI is pretty generic anyways).
Anyways then I'll just proceed testing all the IEs, maybe except the NSEI even since it's already tested somewhere else ;)

Actions #8

Updated by laforge 3 months ago

(at least) our use of "TLV" is more general. Basically it means all the
tag-identified elements usually located after a fixed header of a message.

After all, it's also the TLV parser which we use to parse the TV parts,
TL16V, T16L16V TvLV and many other types of encodings.

Actions #9

Updated by arehbein 2 months ago

I finished some tools to make it easier for me to test and push to Gerrit and am getting the hang of the whole process I think...

About the current state (copy paste from my comment on the WIP commit for this on Gerrit):

This is a first test (the first one I could think of):
The SGSN receives an SNS Size containing the number of IP endpoints
So currently, the test fails.
But I just realized, that the expected cause I coded isn't right.

And I should still add some new tests (I came up with some new ideas now... before it wasn't clear to me, that semantically invalid TLVs were most likely asked for to be tested and I got hung up on trying to find cases for syntactically wrong TLVs (by now I think the only one I can come up with is a number of NS-VCs IE with a length of 1...)

So I'll now look into new testcases (and will probably abandon this one unless it actually still makes sense - I think it doesn't, I misunderstood some of the code) that check semantical validity according to the specs.

Actions #10

Updated by arehbein about 2 months ago

  • % Done changed from 0 to 90

lynxis,

So I have pushed three testcases, I marked them as WIP because they all fail.

I think the case TC_sns_sgsn_sns_size_syntactically_wrong_NSEI (https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30430) fails because our code actually isn't right (the length of `1` given should be too short and hence give back the expected cause).

Concerning TC_sns_sgsn_sns_size_invalid_num_of_ip_eps (https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30431):
My reasoning was to send the 'number of IPv6 endpoints' if IPv4 is supported and vice versa, quote from the TS 148 016:

If the SGSN does not support the type of IP addresses (IPv4/IPv6) offered by the BSS, the SGSN shall send an SNS-
SIZE-ACK PDU with a cause code "Invalid number of IP4 Endpoints" or "Invalid number of IP6 Endpoints".

However it's not clear to me how to determine what endpoints are supported and which ones aren't/how to make a testcase scenario in which to test against that. My guess is our ns/SGSN components support both which is why no error cause is returned - my initial guess was, maybe we interpret "what's configured" as "what's supported", for lack of better knowledge.

Concerning TC_sns_sgsn_sns_size_outgoing_invalid_num_of_nsvcs (https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30432):
I didn't find any info on what the supported number of IPv4/IPv6 endpoints of the SGSN (or our ns implementation?) is.
So my guess was the number of bound IPv4 addresses for the NSVC in the config. That number should however serve as a lower bound to the number of supported IP addresses, so I would say the test failings is actually correct here.

Would be glad to get your input on this

Actions #11

Updated by lynxis 25 days ago

  • Assignee changed from lynxis to arehbein

arehbein wrote in #note-10:

lynxis,

So I have pushed three testcases, I marked them as WIP because they all fail.

I think the case TC_sns_sgsn_sns_size_syntactically_wrong_NSEI (https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30430) fails because our code actually isn't right (the length of `1` given should be too short and hence give back the expected cause).

Nice. So this is a TLV parser test.

Concerning TC_sns_sgsn_sns_size_invalid_num_of_ip_eps (https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30431):
My reasoning was to send the 'number of IPv6 endpoints' if IPv4 is supported and vice versa, quote from the TS 148 016:

If the SGSN does not support the type of IP addresses (IPv4/IPv6) offered by the BSS, the SGSN shall send an SNS-
SIZE-ACK PDU with a cause code "Invalid number of IP4 Endpoints" or "Invalid number of IP6 Endpoints".

However it's not clear to me how to determine what endpoints are supported and which ones aren't/how to make a testcase scenario in which to test against that. My guess is our ns/SGSN components support both which is why no error cause is returned - my initial guess was, maybe we interpret "what's configured" as "what's supported", for lack of better knowledge.

Every SNS endpoint is either IPv4 or IPv6. I would guess our ttcn3 test only doing IPv4 tests atm.
I would implement 2 test cases here. One for IPv4 if SGSN listen on IPv6 and one for IPv6 when SGSN listen on IPv4. You can check which one should be execute and skip the other one.

Concerning TC_sns_sgsn_sns_size_outgoing_invalid_num_of_nsvcs (https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/30432):
I didn't find any info on what the supported number of IPv4/IPv6 endpoints of the SGSN (or our ns implementation?) is.
So my guess was the number of bound IPv4 addresses for the NSVC in the config. That number should however serve as a lower bound to the number of supported IP addresses, so I would say the test failings is actually correct here.

E.g. your PCU has 2 NS binds. Your SGSN has also 2 NS binds (a bind is a ip/udp pair). So we need at least a num_nsvc of 4 to support this configuration.
The num_nsvc is a value to limit the resources on the BSS side. For us we don't care so much if it's 10 or 20. But there must be a limit. (I don't recall but I think it's an arbitrary number in our case).

Actions #12

Updated by arehbein 7 days ago

Nice. So this is a TLV parser test.

Due to TS 148 016 v16, section 8.1 ("General protocol error handling"):

Syntactical error: an IE is defined to be syntactically incorrect in a PDU if it contains at least one value defined
as "reserved" or "reserved for future use", or if its value part violates coding rules specified in the relevant
protocol specification, e.g. a too short IE
(the length indicator shall be used to determine the boundary of the IE).
However, it is not a syntactical error that an IE specifies in its length indicator a greater length than defined in
the relevant protocol specification; and

this appears to me as rather protocol specific, and not generally applicable to TLVs. In the sense of being a TLV, any IE with length 1 containing a single octet as its payload would still be a valid as a general TLV, but it would constitute a protocol error according to TS 148 016 v16 if it is an NSEI TLV.

(The only thing that I don't yet understand is that section 8, as well as section 9 and 10 begin with

This sub-clause is not applicable to the Sub-Network Service protocol.

but from what I can tell, all those requirements are used for SNS messages and procedures as well (if that wasn't the case, then the spec would be missing general information about the SNS protocol...).)

Every SNS endpoint is either IPv4 or IPv6. I would guess our ttcn3 test only doing IPv4 tests atm.
I would implement 2 test cases here. One for IPv4 if SGSN listen on IPv6 and one for IPv6 when SGSN listen on IPv4. You can check which one should be execute and skip the other one.

This is what I tried here (except for not splitting it up in two testcases):

    /* Send IP4 endpoints when IP6 is configured and vice versa, in effect sending an unsupported type of NS-VC endpoints. */
    if (g_nsconfig.nsvc[0].provider.ip.address_family == AF_INET) {
        ts_base_SNS_SIZE_configured.pDU_SNS_Size.numberOfIP6_Endpoints :=
            {iEI := int2oct(enum2int(mp_ns_iei_num_ipv6_ep), 1), numberOfIP_Endpoints := int2oct(NUM_IP, 2)};
        cause := NS_CAUSE_INVALID_NR_OF_IPv6_ENDPOINTS;
    } else {
        ts_base_SNS_SIZE_configured.pDU_SNS_Size.numberOfIP4_Endpoints :=
            {iEI := int2oct(enum2int(mp_ns_iei_num_ipv4_ep), 1), numberOfIP_Endpoints := int2oct(NUM_IP, 2)};
        cause := NS_CAUSE_INVALID_NR_OF_IPv4_ENDPOINTS;
    }
    f_send_expect(IDX, ts_base_SNS_SIZE_configured, cause);

Maybe you can help me understand where my mistake is (I didn't get any errors).

E.g. your PCU has 2 NS binds. Your SGSN has also 2 NS binds (a bind is a ip/udp pair). So we need at least a num_nsvc of 4 to support this configuration.
The num_nsvc is a value to limit the resources on the BSS side. For us we don't care so much if it's 10 or 20. But there must be a limit. (I don't recall but I think it's an arbitrary number in our case).

Yes that's what I understood, but then the test shouldn't fail (?) If I try to send an SNS Size with 3 as the number of max. NS-VCs and the given bind config, I should get back a cause IE with cause code "Invalid number of NS-VCs" (TS 148 016 v16 6.2.4.1:)

If the maximum number of NS-VCs indicated in the SNS-SIZE PDU is less than the number of NS-VCs required for
full mesh connectivity between the peer NSEs, the SGSN shall send an SNS-SIZE-ACK PDU with a cause code
"Invalid number of NS-VCs"

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)