This commit implements part of the OTBR firewall. This implementation
focuses on the ingress filtering part. We may also introduce egress
filtering part when necessary.
For security purpose, there are some packet forwarding rules to
follow, which were originally introduced in the spec.
- Inbound packets initiated with On-Link addresses source (OMR and
mesh local prefix based addresses) should be blocked.
- Inbound unicast packets whose destination address is not OMR address
or DUA should be blocked.
- Inbound unicast packets whose source address or destination address
is link-local should be blocked. Note that we don’t need to
explicitly add rules for link-local addresses since this should
already be handled by the kernel.
These rules can be easily implemented by iptables and ipset.
- Before otbr-agent starts, there is a script creating the iptables
rules. The rules themselves are constant so we don't need to change
them dynamically.
- During the runtime of otbr-agent, otbr-agent updates ipsets
accordingly whenever there's a change of on-link prefixes.
This commit adds a new class `AnycastLocator` which can be used to
locate the closest destination of an anycast IPv6 address (i.e., find
the related mesh local EID and RLOC16). The closest destination is
determined based on the the current routing table and path costs
within the Thread mesh.
The implementation uses a CoAP confirmable post request to a newly
added URI path ("a/yl"). The destination IPv6 address of such as
request message is set to the anycast address to be located. The
receiver of the request message sends a CoAP response which includes
the "Mesh Local EID" and "Thread RLOC16" TLVs.
This commit also adds support this new feature in CLI (adding a new
`locate <anycast-addr>` command).
Finally this commit adds `test_anycast_locator.py` to test behavior of
the new feature.
This commit updates `Srp::Server` to add support for selecting its
address mode (unicast or anycast). The address mode specifies how the
SRP server determines its address and port number and how this info
is published in Thread Network Data.
In anycast address mode, the SRP server will use port number 53 which
is also used by DNS resolver/server. So if both `Srp::Server` and
`Dns::ServiceDiscovery::Server` are enabled on a device, they both
need to listen on the same port number and share the same UDP socket
instance. This commit adds the mechanism in the code to realize this.
The `Srp::Server` will monitor when/if DNS-SD is active and checks
whether the port numbers match and if so it will close its own socket
and re-use the one from DNS-SD. In this case, an incoming UDP message
is first given to `Srp::Server` to process and if it fails to process
it then the message is given to DNS-SD.
This commit also adds CLI commands under `srp server` to get/set the
address mode (and update the `README_SRP_SERVER.md` documentation).
It also adds a new test `test_srp_server_anycast_mode` which covers
the SRP server address mode and the newly added behaviors.
This commit adds a new parameter `aSendUnregToServer` to SRP client's
`RemoveHostAndServices()` API. This parameter determines the behavior
when the host info is not yet registered with the server. If it is
set to `false` (which is the default/expected value) then the SRP
client will immediately remove the host info and services without
sending an update message to server (no need to update the server if
nothing is yet registered with it). If it is set to `true` then the
SRP client will send an update message to the server. Note that if
the host info is registered then the value of `aSendUnregToServer`
does not matter and the SRP client will always send an update message
to the server requesting removal of all info.
One situation where this parameter can be useful is on a device
reset/reboot where the caller may want to remove any previously
registered services with the server. In this case, caller can
`SetHostName()` and then request `RemoveHostAndServices()` with
`aSendUnregToServer` as `true`.
This commit also adds `test_srp_client_remove_host.py` which
verifies the behavior the newly added mechanism between client and
server.
This commit adds History Tracker feature and its CLI support. This
feature records history of different events as the Thread network
operates (e.g., history of RX and TX IPv6 messages or network info
changes).
Recorded entries are timestamped. When the history list is read, the
timestamps are given as the entry age relative to the time the list
is being read. For example in CLI a timestamp can be shown as
`02:31:50.628 ago` indicating the entry was recorded 2 hours, 31 min,
50 sec, and 628 msec ago. Number of days is added for events that are
older than 24 hours, e.g., `31 days 03:00:23.931 ago`. Timestamps use
millisecond accuracy and are tacked up to 49 days. If an event is
older than 49 days, the entry is still tracked in the list but the
timestamp is shown as old or `more than 49 days ago`.
The `HistoryTracker` currently maintains 3 lists. The Network Info
history tracks changes to Device Role, Mode, RLOC16 and Partition ID.
The RX/TX history list records information about the received/sent
IPv6 messages:
- Message type (UDP, TCP, ICMP6 (and its subtype), etc.)
- Source and destination IPv6 addresses and port numbers
- IPv6 payload length
- The message checksum (for UDP, TCP, or ICMP6).
- Whether or not the link-layer security was used
- Message priority: low, norm, high, net (for control messages)
- Short address (RLOC16) of neighbor who send/received the msg
- Received Signal Strength (in dBm) for RX only
- Radio link info (15.4/TREL) on which msg was sent/received
(useful when `OPENTHREAD_CONFIG_MULTI_RADIO` is enabled)
Config `HISTORY_TRACKER_EXCLUDE_THREAD_CONTROL_MESSAGES` can be used
to configure `HistoryTracker` to exclude Thread Control message
(e.g., MLE, TMF) from TX and RX history.
The number of entries recorded for each history list is configurable
through a set of OpenThread config options, e.g., number of entries
in Network Info history list is specified by OpenThread config option
`OPENTHREAD_CONFIG_HISTORY_TRACKER_NET_INFO_LIST_SIZE`. The
`HistoryTracker` will keep the most recent entries overwriting oldest
ones when the list gets full.
This commit also adds support for `HistoryTracker` in CLI. The CLI
commands provide two style for printing the history information: A
table format (more human-readable) and list style (better suited for
parsing by machine/code). `README_HISTORY.md` is added to document
the commands and the info provided by each history list entry.
This commit also adds `test_history_tracker.py` test-case which
covers the behavior of `HistoryTracker`.
Per RFC 4862 section 5.5.3, the SLAAC address of a on-link prefix
will not immediately be invalidated even if the on-link prefix is
sent with zero PIO valid lifetime but we currently removes the
external route for the on-link prefix when we see zero valid lifetime.
This results in an error case that a Thread device can not reach
a valid SLAAC address of a Wi-Fi host on the same infra link because
there is no routes for this address.
This commit fixes this issue by delay removing the external route
for the discovered on-link prefix untill its valid lifetime expires.
Meanwhile, the Border Router now considers a deprecated (zero preferred
lifetime) on-link prefix not usable. Thus, the Border Router will
start advertising its own on-link prefix when current on-link prefix
is deprecated.
This commit implements a new feature "Network Data Publisher" which
provides mechanisms to limit the number of similar entries (service
and/or prefix) in the Thread Network Data by monitoring the Network
Data and managing if or when to add or remove entries. This feature is
enabled using `OPENTHREAD_CONFIG_NETDATA_PUBLISHER_ENABLE` config, or
`NETDATA_PUBLISHER` in autoconf, or `OT_NETDATA_PUBLISHER` cmake
option.
This commit adds support for publishing DNS/SRP anycast/unicast
service, on-mesh prefix, and external route prefix entries.
When there is a request to publish an entry, the `Publisher` monitors
the Network Data and counts the number of similar entries. If there
are fewer entries than a desired target number, the entry is added
after a short random delay.
If there are too many similar entries, `Publisher` starts the process
of removing its own entry (again after some random wait time). When
removing entries, certain entries are preferred over others (e.g., an
entry from a router over one from an end-device or if they are from
the same type of node, the one with smaller RLOC16). If `Publisher`
determines that its own entry is a preferred one, it adds an extra
wait time before removing its entry. This gives higher chance for a
non-preferred entry from another device to be removed before removing
a preferred entry which helps towards quicker convergence of the
process to the desired number of entries.
On-mesh prefix and external route entries have a "preference" field.
When publishing such an entry, a matching entry in the network data is
counted only if its preference is same or higher than the entry's
preference. This ensures that a device with a higher preference entry
publishes its entry even when there are many lower preference similar
entries in the network data (potentially causing a lower preference
entry to be removed).
This commit also adds `test_netdata_publisher.py` to verify the
behavior of the `Publisher`.
This commit includes a test case to verify that multiple border
routers can publish their meshcop services successfully without
instance name conflicts.
This commit adds a new feature in DNS client to automatically set and
update the server's IPv6 address in the default config. This is done
only when user does not explicitly set or specify the server address.
This behavior requires SRP client and its auto-start feature to be
enabled. SRP client will then monitor the Thread Network Data for
DNS/SRP Service entries to select an SRP server. The selected SRP
server address is also set as the DNS server address in the default
config.
This commit also adds `test_dns_client_config_auto_start.py` which
verifies the behavior of the new feature. In particular, that the DNS
client's default config gets changed and mirrors the SRP client
selected server address (when not set by user) and that it remains
unchanged if user explicitly sets the address in the default config.
This commit adds support for service subtypes in SRP server. It
updates the internal data model to store services in `Srp::Server`.
Every `Host` now has a list of `Service` entries along with a list of
`Service::Description` entries. These types mirror the SRP update
message format and the set of instructions that form the SRP message.
The `Service` entries represent the "Service Discovery Instructions",
i.e., the PTR records mapping a service name or a subtype name to a
service instance. A `Service::Description` entry represents the the
SRV and TXT records. A `Service` entry is always associated with a
`Service::Description` and the subtypes of the same service instance
all share the same `Service::Description` entry.
This commit also adds a new method `Host::FindNextService()` and the
public API `otSrpServerHostFindNextService()` which is very flexible
and can be used in different ways. It can be used to iterate over the
full list of services, or over a specific subset of services matching
certain conditions, e.g., iterate over all base services excluding
subtypes, or over all subtypes of an instance, or over all deleted
services, etc. It can also be used to find a specific service with a
given instance and service names.
This commit also simplifies and enhances the logging in `Srp::Server`.
In particular, when a new host is added, we now also log the list of
services being added along with it. Also a change to a `Service` is
only logged if the `Service` is marked as committed. This ensures
that temporary `Service` entries associated with a newly received SRP
update message are not logged (e.g., when an associated temporary
`Host` object is being freed after its content is merged with an
existing `Host` entry).
Finally, this commit adds a test `test_srp_sub_type.py` to cover the
subtype service registration on SRP client and server.
This commit adds new network data service entry definitions to
indicate presence of DNS/SRP servers within the Thread mesh and
provide info about them. Two service TLV formats are added:
`NetworkData::Service::DnsSrpAnycast` indicates that DNS/SRP client on
a device can use the associated anycast address with this service TLV
to reach the DNS/SRP server. The use of anycast address ensures that
the messages are routed to the nearest node which has added such a
service entry in the network data. The service TLV data in this model
contains a one byte sequence number which is used to notify the SRP
clients if they need to re-register with the server(s) (e.g., due
server reset/reboot and/or loss of previous registrations).
`NetworkData::Service::DnsSrpUnicast` directly provides the IPv6
address and port info for a DNS/SRP server which can be included as
part of the service TLV data and/or the server TLV data. Using service
TLV data allows the info about a common infrastructure SRP/DNS server
to be added by multiple BRs. In the case of server TLV, the IPv6
address info can be optionally omitted (i.e. just a port number is
provided) which then causes the associated RLOC/ALOC address of the
node who added the service entry to be used as the server's IPv6
address.
This commit updates the `Srp::Client` to use the new service entries
to discover/select the SRP sever when auto-start mode is enabled. The
client prefers and uses a `DnsSrpAnycast` over `DnsSrpUnicast`
entries. The `Srp::Server` is also updated to publish its info as
`DnsSrpAnycast` entry (using mesh-local address).
This commit also updates the `test_network_data` unit test to cover
the behavior of newly methods which iterate and parse different
service entry formats.
The commit enhances the Routing Manager to learn RA header and
parameters from RA messages initiated from infra interface. This
addresses the issue that the BR may be using different RA header
against another RA daemon which is working on the same infra interface
(Have BR and another RA daemon working on the same interface is common
for Wi-Fi + Thread routers).
We also changed to accept RS messages initiated from the infra
interface: this is for case that multiple Border Routers run on the
same host (as we are trying to support multiple ot-daemons on the same
host).
This commit implements DNS-SD Discovery Proxy.
- Implemented DNS-SD Discovery Proxy functionalities - OT part
- Fixed an memory issue of NameCompressInfo (introduced in #6155 , but
somehow revealed by this commit)
Some implementation details:
- Discovery Proxy subscribes to services/service instances/hosts
through callbacks set by a public OT API. It is up to the platform
mDNS implementation to collect service instance/host information and
notify OT via a public OT API.
- Discovery Proxy can handle DNS browsing of one service or DNS
resolving of one service instance/host. We leave browsing multiple
services or resolving multiple service instances/hosts for future
enhancements if necessary.
Accept RA initiated from the infra interface so that we can detect the
existence of another RA daemon which is working on the same infra
interface.
Also enhance the test_single_border_router.py test script to make it
more readable.
- Ping command in CLI will print Done in the end, after printing
replies and statistics. The old behavior is, ping command prints
Done before any replies.
- In OTCI, let ping function return statistics.
- Support timeout parameter in ping command.
- Fix a bug that the arguments are not properly passed to ping in
node.py.
- Adjust timeouts in tests.
There is an issue that the SRP host or service are not deregistered by
the Advertising Proxy when the host or service is expired. This is
because we didn't notifies the Advertising Proxy of the host/service
expiration. This commit fixes this issue and adds tests for it.
This commit includes below changes:
- handles dynamic infrastructure interface status changes. The Routing
Manager will be started if the infra interface status turns to be
RUNNING and a valid link-local address is present. Otherwise, the
Routing Manager will be stopped.
- changes the default status of the Routing Manager from enabled to
disabled and it is initially enabled for the posix platform.
- the posix implementation now doesn't require the presence of the
link-local address at initialization stage. In this case, the
Routing Manager will not be started before a link-local address is
added to the infra interface.
- add CI tests for the new behavior.
This commit adds a new public `ot` API for parsing an encoded DNS TXT
record data into `TxtEntry` key/value pairs. It also updates the TXT
data iterator model used for going through all TXT entries. The new
iterator definition provides a small buffer to store the key string.
This helps simplify the definition of `otDnsTxtEntry` to use
null-terminated C string for the key. The new parsing APIs are used in
CLI module.
This commit also fixes an issue with `TxtEntry::AppendEntries()` using
incorrect value for the key length.
Finally, this commit adds a test covering the behavior of all
`TxtEntry` related methods (encoding and parsing TXT data) in the unit
test `test_dns`.
This commit adds auto-start SRP client feature. Config option
`OPENTHREAD_CONFIG_SRP_CLIENT_AUTO_START_API_ENABLE` adds support for
this feature in SRP client allowing auto-start mode to be enabled or
disabled. When enabled, the SRP client will monitor the Thread Network
Data for SRP Server Service entries and automatically start and stop
the client when an SRP server is detected. If multiple SRP servers are
found, a random one will be selected. If the selected SRP server is no
longer detected (not longer present in the Thread Network Data), the
SRP client will be stopped and then it may switch to another SRP
server (if available).
This commit also adds support for the new feature in CLI and adds a
new test `test_srp_auto_start_mode.py` covering the behavior of this
feature.
This commit enhances the DNS-SD server to handle multiple questions.
Specifically for DNS service resolving query with SRV+TXT questions,
this commit would reply with SRV+TXT+AAAA RRs, so that the service
instance can be fully resolved with one query.
More implementation details:
- This commit enhances NameCompressInfo so that question names can be
compressed together with RR names.
- Full compression is limited to only one instance / service / host
name.
- For any RR type in the question, this commit will exclude it in
additional RRs. For example, if the query contains a AAAA question,
the response won't include any additional AAAA RR, but will only
have AAAA answer(s). The purpose is to avoid duplicate RRs in answer
section and additional section.
This change:
1. Adds new github action to verify posix app for OT 1.2.
2. Only enable compile flag OT_SIMULATION_VIRTUAL_TIME_UART in
script/test for ot-rcp build target.
3. Allow mix use of posix node and ot-cli-mtd node by changing python
test script to accept node type as parameter.
4. Remove CSL test from expect as it is covered by thread-1-2-posix
tests.
This commit implements the DNS-SD server:
- Handle Standard DNS Query from clients
- Supported resource records: PTR, SRV, TXT, AAAA
- Query services from SRP server
- Add tests
- simulation test using DNS client (only test AAAA query)
- OTBR test using dig command to verify all resource records can be
queried successfully
This commit includes basic service registration & advertising function
verification. More tests including name conflicts and multiple devices
cases will be in future commits.
We changed the border_routing test scripts directory to border_router
as there will be more tests about Thread border router but not only
the routing feature.
Simon Lin