On 08 Feb 2013, at 09:36 , Brian E Carpenter wrote:
> Me too. TCP is also an encapsulating header; its contents
> just don't happen to be encrypted. The draft's definition
> of "Entire IPv6 header chain" uses TCP as an example:
>
> Note: If there is an upper layer header, only the header (and
> not its payload) are considered part of the "entire IPv6 header
> chain". For example, if the upper layer protocol is TCP, only
> the TCP header (and not its possible data bytes) should be
> considered part of the "entire IPv6 header chain".
>
> but I don't think it would be any different for ESP.
>
> However, I do see one point that is under-defined right now:
>
> **How many bytes of the transport header+payload are included in this
> definition?**
>
> For ESP, is it 8 bytes (SPI + Sequence Number)?
I think that would be OK. Certainly it MUST NOT be
more than those 8 bytes, because beyond there lies
encrypted bits (in the general case).
I actually believe that the SPI alone would suffice
for ESP.
> For TCP, is it 8 bytes (ports + Sequence Number)?
My own sense is that Source Port and Destination Port,
so 32 bits, actually would suffice, but I'll at least
note one possible counter-argument:
A firewall implementation might want to look
at the TCP flags to check for invalid flag
combinations.
For UDP, my own sense is that the first 32 bits
would suffice, although I don't see any harm in
including the first 64 bits.
I would have no objection to Fernando adding more
detail for the obvious terminating payloads
(e.g. UDP, TCP, SCTP, ICMP, ESP) to the draft.
Adding more clarity about this to the I-D could not hurt,
and might help some implementers.
Yours,
Ran
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
