151 bugs in network connectivity inference #168
Conversation
… yet tested due to #154.
…sue, splitting CNSRAN-p+BS so it adds a location for the inferred base station in a private (but not public) cellular network.
…es) to and from USB or Bluetooth pairing connections.
- Added prohibited nodes to MP-L3c-rGc-rL3 and MP-L3rGc-rL3 used by IP routing inference patterns, for consistency with changes for issues #152 and #157. - Deleted CP-LPLRTSg-f+b, which encoded routing constraints involving tethered connections, which are now handled by changes elsewhere for issues #152 and #157. - Deleted threats Sg.A.LTRevSg2.6.1, Sg.TA.LTRevSg2.8 and Sg.TA.LTRevSg2AC.1, which are rendered redundant by changes for issue #157. - Fixed bugs in patterns CP-L3cGrL1+CSg and CP-L1cGcL3+NSg or their matching/root patterns, regression errors in changes for #157. - Fixed bugs in patterns CP-PCNSRAN-p+BS and CP-UCNSRAN-p+BS, so they relate to private/public cellular networks, errors introduced by changes for #152.
…fter fixes for #157, plus other tidying up.
…o longer needed for this issue.
…ruction sequence.
…e previously overlooked.
…tion for inferred association of a base station, plus some tidying up of icons, labels and descriptions.
…d a palette type overlay parent class.
|
I've been able to start looking at this Pull Request; two quick questions @mike1813 just to double check, in (e.g.) the test model Issue-151-Test-01d of issue #151 I find a modelling error that there is no network path from C2 to S4, is this intended behaviour? Also, I find no network path modelling error between C4 and S2, is this also intended behaviour? |
This is the intended behaviour in both cases. In Issue-151-Test-01d the following client-service connections should have no network path:
You didn't mention C1-S2, so I guess that one was more obvious. All the other client-service connections (C1-S1, C1-S4, C3-S2 and C4-S1) should be OK. In the case of C3-S2 this is arguably not OK. The two hosts are in the same cell, but access from C3 to S2 would be via the base station in that cell, which would probably be blocked. This can't be done with our current implementation. It is covered by a separate issue #159, which was left for a later update. |
The source branch incorporates several developments to fix issues found in a test case involving a private cellular network which was partially asserted (a situation not anticipated when the cellular network construction sequence was created).
Issues addressed are as follows.
Issue #151: this was a sequencing error whereby some inference patterns that depended on HprLS+c were triggered before HprLS+c. Fixed by reordering these and related patterns into three groups, applied in this order:
Issue #152: this was the issue concerning the need to allow for the possibility that users may want (or try) to assert part of a cellular network infrastructure. Fixed by splitting the existing patterns into several patterns so that each inferred asset could be added separately, if and only if it was not already present. To make this work it was also necessary to refine relationships between logical subnets and abstract subnets implemented by the logical subnets. In particular, these relationships had to become assertible when used in cellular networks but not when used in WiFi hotspot models. For that reason, new subtypes had to be used.
Note that the existence of a new assertible relationship types does not in itself create a backward compatibility issue w.r.t. system models. Old models will not include these relationship at all, and it should be necessary to add them only in models that don't work properly because they are affected by issues #151 or #152. However, see below.
The new relationships did raise an issue for the domain model which has been fixed:
The resequencing for issue #151, combined with the refactoring of construction patterns for issue #152 led to other sequencing issues. In addition, tests uncovered other bugs exercised by corner cases that were masked before by the old sequencing. The following accessibility inference corner cases were found and addressed:
Then comes HprLS+c, which inserts the connection between a subnet and its providing host, plus interfaces. There is a possible bug in pattern ILSA+c, described in issue #167. It doesn't seem to cause a problem, and it certainly doesn't affect test cases for issues #151 and #152, so it has not been addressed yet.
After the host-subnet connection and interface inference, comes logical path segment inference - i.e., routes through gateways. This sequence has also been reorganised and made more resilient by adding checks to ensure that segments are not created if they duplicate a previously inferred segment. The order of segment generation is now:
The cellular network segment generation patterns have been refactored so we get different segment classes and hence routing restrictions in private cellular networks. These changes are part of the solution to issue #152.
Here too, some older bugs and corner cases were found and fixed:
This is followed by network path inference, and then service channel creation where another old bug was found:
In addition, a new feature was identified as necessary to complete the delineation between public and private cellular networks. In public cellular networks, client devices are not trusted, so there routing restictions are used to prevent users running services accessible from outside the cellular network, or from outside the user's cell. However, it is impossible to model a restriction preventing service access between devices in the same cell. This is due to a limitation in the model for a network path, which was documented as issue #159, but not addressed in these changes.
The changes in logicsal segmen inference patterns for issues #152 and #157 have produced genuine system model backward compatibility issue. This is due to the fact that the logical segment classes have changed, and hence the URIs of the generated segments have changed. Any user assertions referring to the old URIs (e.g., controls or impact levels) will need to be replaced.