[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: minor inconsistency in arch doc (maybe)
Charles Lynn wrote:
<trimmed...>
> I think that the "problem" arises from the
> ambiguity of the term "Transport Layer Protocol". In a sense, ESP is a
> transport layer protocol (to the closest preceeding IP header), but AH
> isn't. As the concepts become more complex, the simple terminology that
> was previously clear may not keep up with our more refined concepts.
<trimmed...>
Yes, this seems to capture it succinctly. More below.
> > Is the confusion here due to IPv4 vs IPv6 differences, or what?
> I do not think so.
>
> When I read the text you cited, from an implementor's perspective, what I
> see is a warning. The field in a packet corredsponding to "Transport Layer
> Protocol" is no longer a simple object to find. It may be in the IPv?
> header, or it may be in one of possibly several extension headers (note
> both that anything the implementation does not "understand" becomes a
> transport protocol, and that some folks are using "extension headers" in
> IPv4, and not just AH). So when the code to find the field is written, it
> may have to be called several times to check successive places in a packet
> (returning "OPAQUE" when it cannot find any more), or the function may
> return a list of values, depending on how one implements things.
>
> At one point (if I remember correctly :-), there was another selector that
> tried to distinguish between "Transport Layer Protocol" and extension
> headers. It was removed, maybe because it made things "too complex".
> The complexity does not go away, it just permutes into a different form.
>
> Does this correspond to your understanding of what is needed to support the
> types of policies we need? Do you have any suggestions for clearer text?
I think the confusion centers on the term 'Transport', and relates to
the ambiguity of that term with respect to such protocols as ESP or AH,
as you said. The text seems to imply that you should search forward in
the packet to find the 'transport' protocol if the 'next protocol' value
in the IP header is ESP/AH. This confuses me a bit. If it's okay to use
*whatever* protocol is in this field as a selector, then perhaps we
should consider omitting 'transport' in this context.
I should add that if we are talking about 'IP security' as opposed to
'transport layer security', it may be argued that it would be
inappropriate to select based upon something in the packet *other* than
the IP header fields (and IP options, which are arguably an extension of
the IP header). However, I admit that I haven't given this a lot of
thought.
Scott