Hi,
I have some comments on draft-ietf-ipsecme-diet-esp-02.txt.
Section 2:
Old:
An ESP packet is composed of an ESP Header, an ESP Payload and an
Integrity Check Value (ICV). and ESP Trailer.
Maybe better:
An ESP packet is composed of an ESP Header, an ESP Payload, an
ESP Trailer and an Integrity Check Value (ICV).
Section 4:
Figure Figure 2 -> Figure 2
Figure 2:
Maybe: ESP (unwrapping) -> ESP (Decapsulation)
In Figure 2 is a fied 'IPv6 + ESP'. Do we really have a full ESP
header after the compression, or is SCHC(ESP Header) following
the IPv6 header?
Section 4.1:
In Figure 3 is a field 'Compression Residue'. The definition
does not define this, instead there is a 'Maximum Packet Size'
defined.
Setion 4.3:
In particular, Diet-ESP restricts the
Traffic Selector to a single type of IP address (i.e., IPv4 or IPv6),
a single protocol (such as UDP, TCP, or not relevant), a single port
range, and multiple DSCP numbers.
Is the DCSP value really defined as a TS?
Figure 5:
Old:
| tunnel_ip | IPv6 address | RFC4301 | CTEC |
Maybe:
| tunnel_ip |IPv4 or IPv6 address | RFC4301 | CTEC |
The defintion of esp_spi_lsb says:
esp_spi_lsb: designates the LSB to be considered for the compressed
SPI. A value of 32 for esp_spi_lsb will leave the SPI unchanged.
This parameter is defined by this specification and can take the
following values 0, 1, 2, 4 respectively meaning that the
compressed SPI will consist of the esp_spi_lsb LSB bytes of the
original SPI. A value of 4 for esp_spi_lsb will leave the SPI
unchanged.
I guess either a value of 32 or value of 4 for esp_spi_lsb will
leave the SPI unchanged, not both.
Maybe:
esp_spi_lsb: designates the LSB to be considered for the compressed
SPI.
This parameter is defined by this specification and can take the
following values 0, 1, 2, 4 respectively meaning that the
compressed SPI will consist of the esp_spi_lsb LSB bytes of the
original SPI. A value of 4 for esp_spi_lsb will leave the SPI
unchanged.
Btw. how is the original SPI reconstructed at the receiver?
Is the SPI value space restricted then?
Section 5.4:
The IPv6 Next Header field or the IPv4 Protocol that contains the
"ESP" value is changed to "SCHC".
This means that we need a new protocol ID for SCHC. Is it really worth
of it, given that EEC can save at most 7 bytes for some odd IOT devices?
Maybe it is better to leave the ESP header as is and do Header Compression
just for the rest of the packet.
Steffen
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
