Re: Transmission of RsvdULP in each segment or an RDDP message

Caitlin Bestler <[email protected]>
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Nov 13, 2003, at 4:04 PM, Barry Reinhold wrote:

Folks,
	I'm playing a bit a catch up here and may be exhuming old
bodies, but could someone motivate the rational behind this pp?

         The RsvdULP field is opaque to the DDP protocol and can be
         structured in any way by the ULP. At the Data Source, DDP
MUST
         set RsvdULP Field to the value specified by the ULP. It is
         transferred unmodified from the Data Source to the Data Sink.
         At the Data Sink, DDP MUST provide the RsvdULP field to the
ULP
         when the DDP Message is delivered. Each DDP Segment within a
         specific DDP Message MUST contain the same value for this
         field.

In particular I don't understand the motivation for the last
sentence.
- From a conformance point of view I have to test this statement for
both
the xmitter and receiver. For the receiver this would be done by
generating a DDP message with N DDP segments. I would then run N
trials
in which one of the N segments has a modified RsvdULP field in the
header. This would verify that the receiving DDP entity checked the
field (The receiver check has to be done given the MUST -- since MUST
is
only used for requirements that impact interoperability - this is an
implicit rule that the receiver checks or uses this -- otherwise it
doesn't impact interoperability). I'm sure people are not planning on
having their receiver code check this.

I think a better way to write this would be to have the receiver only
look at this field when the L bit is set. If the L bit is not set the
field should be ignored.



I suspect that everyone is planning on implementing it that way.

The difference is in the interpretation of what a MUST requirement
on the Sender means to the receiver.

	If the Sender MUST do X, then the Receiver MAY simply assume
	that it has done so.

	But it SHOULD NOT do so if this creates a security vulnerability.

In this case there is no security vulnerability, the receiver is
thoroughly not impacted by fields that it ignores. So the fact
that they MUST be the same frees the receiver to examine only the
one with the L bit set.

It also means that if some implementation came up with a way to do
speculative work base on an early field it could, knowing that the
final one will have the same value. (I can't think of anything right
now, but in theory you could).


- --
Caitlin Bestler - [email protected] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBP7Qm/LY6y5WqUdvJEQI86ACfbvG4WZ/Okg5mNYpuIglGRtJv9EwAoMro
DlxZzWPhW2J/t2RC86trlUl2
=hu0c
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.