Skip to content

Commit b882b46

Browse files
committed
npep-187: More protocols support
Signed-off-by: Nadia Pinaeva <[email protected]>
1 parent 563e4ba commit b882b46

File tree

1 file changed

+104
-0
lines changed

1 file changed

+104
-0
lines changed

npeps/npep-187-ports-and-protocols.md

+104
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,104 @@
1+
# NPEP-187: More protocols support
2+
3+
* Issue: [#187](https://github.com/kubernetes-sigs/network-policy-api/issues/187)
4+
* Status: Provisional
5+
6+
## TLDR
7+
8+
Change existing `ports` selector to allow more protocols in the future.
9+
10+
## Goals
11+
12+
Change existing `ports` selector to allow more protocols in the future.
13+
14+
## Non-Goals
15+
16+
Adding new protocols to the API.
17+
18+
## Introduction
19+
20+
Currently only TCP, UDP, and SCTP protocols are supported, but there are more protocols (ICMP, ICMPv6 are the most popular requests)
21+
that may be useful.
22+
23+
## User-Stories/Use-Cases
24+
25+
Story 1: Protocols extension
26+
27+
As a cluster admin I want to be able to use protocols other than TCP, UDP, and SCTP in my ANP.
28+
For example, I want to only allow ICMP connections to implement health monitoring and deny everything else.
29+
30+
## API
31+
32+
As we only support port-based protocols (TCP, UDP, and SCTP), current protocol matching is expressed as
33+
```yaml
34+
ports:
35+
- portNumber:
36+
protocol: TCP
37+
port: 80
38+
- portRange:
39+
protocol: UDP
40+
start: 1
41+
end: 100
42+
```
43+
To enable more protocols support in the future, we need to change the high-level field name from `port` to `protocol` to be more generic.
44+
45+
In the `protocols` filter design we decided to start from the YAML that we want (i.e. YAML that is easy to write and understand).
46+
We want to make popular filters (TCP and UDN ports) easy and less popular filters (like ICMP and named ports) possible.
47+
This brings us to the following design:
48+
49+
```yaml
50+
protocols:
51+
- protocol: TCP
52+
port: 8080
53+
- protocol: UDP
54+
portRange:
55+
start: 8080
56+
end: 9090
57+
- namedPort: http
58+
# protocol: "" # must be empty string: defaulted / omitempty
59+
```
60+
61+
with the validation like so:
62+
- empty `protocols` list is not allowed
63+
- at least 1 field for each `protocol` element must be set
64+
- if `namedPort` is set, `protocol` must be unset
65+
- if `protocol` is TCP/UDP/SCTP, `port: int` or `portRange: {start: int, end: int}` must be set, but not at the same time
66+
67+
Using ICMP as a potential example for a pure protocol match (`protocol: ICMP`) or protocol with extra fields (e.g. ICMP type and code),
68+
a future extension could look like this:
69+
70+
```yaml
71+
protocols:
72+
# option 1: A little inconsistent with port match as it has an extra `icmp` field instead of flat parameters
73+
- protocol: ICMP
74+
icmp:
75+
type: 7
76+
code: 3
77+
# option 2: Flat parameters, may conflict with the future protocol that also have type or code
78+
- protocol: ICMP
79+
type: 7
80+
code: 3
81+
# option 3: Same as option 1, but without a discriminator (protocol)
82+
- icmp:
83+
type: 7
84+
code: 3
85+
```
86+
87+
## Conformance Details
88+
89+
(This section describes the names to be used for the feature or
90+
features in conformance tests and profiles.
91+
92+
These should be `CamelCase` names that specify the feature as
93+
precisely as possible, and are particularly important for
94+
Extended features, since they may be surfaced to users.)
95+
96+
## Alternatives
97+
98+
(List other design alternatives and why we did not go in that
99+
direction)
100+
101+
## References
102+
103+
(Add any additional document links. Again, we should try to avoid
104+
too much content not in version control to avoid broken links)

0 commit comments

Comments
 (0)