[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: clarification
Folks,
It has been pointed out that my earlier message is not right.
Specifically, I said:
> When we had "opaque", one could place the policy entry containing opaque
> protocol and ports either before or after policy entries with the same
> source and destination addresses and explicit protocol and ports; but
> opaque has been removed so that freedom is no longer possible.
"Opaque" is still a SHOULD, so the correct statement is:
One can place the policy entry containing opaque protocol and ports
either before or after policy entries with the same source and
destination addresses and explicit protocol and ports.
I have also heard the opaque should be defined -- i.e., the value of
the field from a packet is not available, either because of an ESP
header or because of fragmentation.
> If one makes the explicit wildcard SPD entry choice, as you are
> suggesting, then the result is that the entry is essentially "after".
> Trying to place it before the explicit entry would effectively hide the
> explicit entry since anything that would match the explicit entry would
> also match the wildcard entry preceding it.
This might be stated as:
It does not make sense to place an SPD entry for ANY (e.g.,
WILDCARD) before the SPD entry for an explicit value as the ANY
entry would effectively hide the entry for the explicit value, since
anything that would match the explicit entry would also match the
wildcard entry preceding it.
The following paragraph should be ignored:
> If one makes the "derive (protocol and) port selector value" choice, as
> the document is written, then one has a single SPD entry that is a
> combination of the two. However, one has the possibility that the SPD
> entry that will be matched is not the "expected" one, but some previous,
> possibly explicit, SPD entry that has the same source and destination
> addresses, but different (protocol and) port selectors.
Sorry for any confusion I might have caused.
........................................................................
> At 11:41 AM 3/12/98 EST, you wrote:
> >Rohit,
> >
> > Next Hdr Next Hdr Derived Port Selector Field
> > in Packet in SPD Value in SPD and SAD
> > --------------- -------------- ----------------------------
> >
> > 1) ESP ESP or ANY ANY (i.e., don't look at it)
> >
> > 2) -don't care- ANY ANY (i.e., don't look at it)
> >
> > 3) specific value, specific value NOT ANY (i.e., drop packet)
> > fragment
> >
> > 4) specific value, specific value actual port selector field
> > not fragment
> >
> >What the table is trying to convey is that there are interactions
> >between the selectors used to match SPD or SAD entries themselves and
> >also with fields in a packet that are not classified as selectors,
> >i.e., the fragmentation fields. It tries to be "implementation
> >neutral" by specifying certain port selector values that result in the
> >desired behavior.
>
> rohit>> can you elobarate on "fragmentation fields " ?
> rohit>> What is the meaning of "implementation neutral"?
"Fragmentation fields" means those fields in an IP datagram that
indicate that the datagram is a fragment. For an IPv4 header, a
fragment is indicated by either the Flags field having Bit 2: (MF) set
to 1, or a non-zero Fragment Offset field. A fragment is also
indicated when there is a Fragmentation Header with either a non-zero
Fragment Offset, or the M bit is set to one.
"Implementation neutral" means that the document is not suggesting use
of a particular way to implement the desired functionality. A vendor
can use any mechanism that results in the correct behavior.
> >In cases 1), if the protocol field in the packet identifies an ESP
> >header, and the protocol selector specifies either ESP or a wildcard,
> >i.e., the protocol matches, then one cannot use the port selector for
> >anything as one cannot find port values in the packet to be matched
> >against the selector values in the SPD or SAD. The easy way to
> >specify that "there are no useful port value(s) in the packet" is to
> >specify the source and destination port selectors as a wildcard -- ANY.
>
> rohit>> Where we have to specifiy ? Since policies in SPD has been
> already entered by system administrator, whether it leads to the
> modification of the policy ( i.e Selector_Val_Type )
As you say, the policy has been specified in the SPD. The table does
not mean that the SPD is modified, but that it does not make sense to
specify an explicit port value when one has specified a protocol of
ESP, or does not care what protocol is being used.
> rohit>> ANY means either packetvalue/SPDValue / wildcard , not just
> wildcard , is it right ?
I do not think so. It meant that the packetvalue was not available to
be compared to the SPDValue, and a way to specify that there was no
meaningful comparrison is to specify a wildcard.
The distinction, in my mind, between a wildcard (ANY) and OPAQUE is
that a wildcard will match any explicit value in the packet while
OPAQUE would not match any explicit value, only "no value available".
However, the IPSec DOI does not currently specify a way to express
OPAQUE (maybe one could define 65535 to mean OPAQUE port and 255 to
mean OPAQUE protocol), so there is an inconsistency here that should
be addressed.
>Otherwise in case 2), if the one allows any protocol, then it does
>not make any sense to try and specify some explicit port number, so
>again, one should ignore the port selectors by specifying ANY port.
rohit >> Again where we should specify ?
Again, in the SPD entry entered by system administrator.
Charlie
Follow-Ups: