[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: clarification
Charlie,
> For IPv4 yes (assuming one isn't using Extension Headers in IPv4,
> which is happening), for IPv6 maybe not, as the Next Hdr field in the
> Fragmentation Header might not identify a transport protocol (e.g., it
> could be Destination Options).
Yes, this is true. One might be able to chain down to the transport
header but only on the first fragment if it was big enough. I think
Dst opts could be forbidden by an administrater in this case so that,
in return, he/she could do transport protocol (and port) enforcement on
fragments. I agree that this isn't a great answer and there may be
other headers as well at some point that interfere.
> > So, for Case 3 I'd think that any of the following are possible when a
> > specific-value for protocol on a fragment coming through an SA is specified:
> > "NOT ANY" (drop, we don't like fragments through this SA)
> > "ANY" (don't look for ports, whether there or not pass the fragment)
> > "actual port" (check if this fragment can contain them, else "ANY")
>
> I do not think that the first two options would not require any code changes,
> so would "only" impact product documentation. I think that the third would
> also require a code change for some vendors. What do others in the working
> group think about changing the minimum required functionality for fragments?
I'm satisfied with not changing the minimum functionality as long as
implementations are free to have additional/conflicting selector rules,
including not discarding specified transport protocol/port fragments.
It seems obvious but just wanted to make sure there wouldn't be an
IPSEC conformance or interop issue.
Thanks.
-- Marc --
>
> 3a) specific value, specific value NOT ANY (i.e., drop packet), or
> first fragment ANY (pass the fragmented packet), or
> actual port selector field
>
> 3b) specific value, specific value ANY (pass the fragmented packet)
> other fragments
>
> Charlie
>