[Css-csts] Action Item #02-0511S: Annex E with simplified
service state tables
John Pietras
john.pietras at gst.com
Tue Aug 30 14:07:52 EDT 2011
Martin,
Thanks for the excerpt from the FW specification. The paragraphs that
apply to the 'not-authenticated PDU' issue are 3.2.4.5.1.1, 3.2.4.5.1.2,
and 3.2.4.5.1.5 (Note - these numbers appear to be incorrect - I believe
that they should be 3.2.4.6, 3.2.4.7, and 3.2.4.8). Based on these
paragraphs, I still believe that it is appropriate to have the
'not-authenticated PD" case called out in the service state tables (E-1
and E-5) because it is true for the service: the decision to remove it
from the Association Control state table was because we (the WG) decided
that it was unnecessary and inappropriate to assume that the Association
Control procedure would "see" a PDU that failed authentication. However,
I might suggest a more correctly descriptive name for the incoming event
- 'PDU failed authentication' ('not authenticated PDU' could be
incorrectly interpreted to refer to a PDU when the authentication level
is 'none'). The reference for the 'not authenticated PDU' or 'PDU failed
authentication' event should be to what is now paragraph 3.2.4.5.1.1,
although as stated above I think the number should really be 3.2.4.6.
In addition, I realized while reading through the excerpt that you sent
me that I should have included an 'invalid PDU' incoming event in state
tables E-1 and E-5. In the December draft version of the FW, every
procedure state table had an 'invalid PDU' event. In Berlin, we decided
to remove the 'invalid PDU' events from the individual procedure state
tables because we determined that individual procedures are not able to
"see" some of the conditions by which a PDU would be invalid (e.g., if
it has an invalid procedure type identifier, it will never be submitted
to a procedure that could recognize it). Instead, we added a statement
in section 3.2.3 to say that in the case of an invalid PDU the
association would be aborted (3.2.3.8) and a NOTE that says that the
invalid PDU case "is not addressed elsewhere in this Recommendation"
[Note - should be "Recommended Standard"]. When I re-did Annex E earlier
this summer, I forgot that we had removed 'invalid PDU' for the
individual procedure state tables. It should be added the E-1 and E-5
because otherwise it would appear nowhere in any state table. The
reference for the 'invalid PDU' event should be to paragraph 3.2.3.6.
Finally, in the December draft version of the FW, paragraph 3.2.3.6
included a bullet that stated that one of the reasons for considering a
PDU to be invalid is that "it is invalid in the current state of the
procedure". In discussing this in Berlin, we decided that this was not
"invalid" in the sense that it would always cause a peer-abort, and this
bullet was pulled out to become a new paragraph by itself (3.2.3.7) "A
PDU shall be considered unexpected if it is invalid in the current state
of the procedure" with the NOTE "The unexpected behavior is addressed in
each procedure". In thinking about it more closely, this requirement is
unnecessary. First, it primarily exists to coin a new term/condition
"unexpected PDU", which is never used elsewhere in the specification.
Second, and more important, it is unnecessary to state this in section 3
because each state table explicitly shows for each incoming PDU what
happens in each of the states of the procedure without ever having to
label the PDU expected or unexpected. So my recommendation is to delete
3.2.3.7 as unnecessary.
Best regards,
John
From: Martin Karch [mailto:martin.karch at vega.de]
Sent: Tuesday, August 30, 2011 12:17 PM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; 'Margherita.di.Giulio at esa.int';
Yves.Doat at esa.int
Subject: RE: [Css-csts] Action Item #02-0511S: Annex E with simplified
service state tables
Dear John,
please find attached, as desired, section 3.2 of the Book. The section
contains the updates made in the Berlin meeting so far.
I have only one comment to your comments, and this time it is in black
(see below).
Best regards,
Martin
From: John Pietras [mailto:john.pietras at gst.com]
Sent: 29 August 2011 22:34
To: Martin Karch
Cc: css-csts at mailman.ccsds.org; Margherita.di.Giulio at esa.int;
Yves.Doat at esa.int
Subject: RE: [Css-csts] Action Item #02-0511S: Annex E with simplified
service state tables
Martin,
Please see my responses below, in red.
John
From: Martin Karch [mailto:martin.karch at vega.de]
Sent: Friday, August 26, 2011 8:35 AM
To: John Pietras
Cc: css-csts at mailman.ccsds.org; 'Margherita.di.Giulio at esa.int';
Yves.Doat at esa.int
Subject: RE: [Css-csts] Action Item #02-0511S: Annex E with simplified
service state tables
Dear John,
Please find attached a PDF file of Annex of the Book, which Yves
prepared according to your input "SimplifiedStatefulAnnexE.zip" and
according to the following comments to 921x1r2[Draft
201012]-Annex_E-clean.pdf:
- In Table E-2 there is the event 'abort-causing event xxx',
but this one is not available in the state table E-1. In Table E-1
position 2 there is 'abortable event xxx'. Perhaps this one needs to be
exchanged with 'abort-causing event xxx'.
Agreed. I had actually hand-marked that inconsistency to be fixed in my
hardcopy, but I obviously didn't do it.
- In Table E-1 position 1: we feel that in the cell for State 2
there is a {cleanup} missing. If a BIND invocation is received in the
state 'bound' there might be some returns pending, and/or some parameter
values might have changed already. Therefore we feel that also in this
case a {cleanup} is needed after the PeerAbort.
Agreed.
- Table E-2: The event 'not-authenticated PDU' was removed from
the Access Control Procedure State Tables (in Berlin). A reference to
'invalid PDU' should also not be made because we agreed to remove
'invalid PDU' from all the state tables. Therefor we think we do not
need the entry in table E-2, and then also not in E-1.
I remember that we agreed to remove this incoming event from the Access
Control procedure state table, and someone came up with some clever
words that specified the handling of authentication failures without
reference to the Access Control (or any other) procedure. However, since
annex E deals with the state tables for the services themselves, it
might still be appropriate to identify non-authentication of a PDU as a
service-level incoming event. Could you please send me the text for
section 3.2 (updated to include the new wording that was agreed in
Berlin) so that I can see if I agree that it's okay to delete this
incoming event from the service state tables? Thanks.
- Table E-5: The same problem as describe above with the
'abortable event xxx'/'abort-causing event xxx' exists in Tables E-5 and
E-6.
Agreed.
- Table E-5: Also here we feel that the 'not authenticated PDU'
is not needed here.
See response above.
- The Predicate Description Table and Compound Definitions
Table are missing on page E-6.
In E3.8, I stated that tables E-2 (Event Description References), E-3
(Predicate Description Table) and E-4 (Compound Definitions Table) were
also applicable to the stateful state machine case, in order to not
repeat the tables. Actually, I made a slight mistake - I should have
only referenced tables E-3 and E-4, since E-6 replaces E-4 for the Event
Description References. In any case, I can see how this cross reference
is perhaps too subtle, and just explicitly repeating the Predicate
Description and Compound Definitions tables may be easier for the
reader. However, if the new tables E-7 and E-8 are kept, then paragraph
E3.8 should be changed to read "Each CSTS that has a stateful prime
procedure instance shall conform to the state table for a CSTS with
stateful prime procedure instance defined in table E-5, supported by
information in tables E-6 through E-8."
>> One intention for the comment was indeed that it is
more convenient for the reader to actually see the tables (even if there
is only one entry), rather than to read where he could look-up another
table. Therefore I agree with your described approach to keep the tables
E-7 and E-8 and adapt the description in E3.8 accordingly.
Best regards,
Martin
From: css-csts-bounces at mailman.ccsds.org
[mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: 01 June 2011 20:47
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Action Item #02-0511S: Annex E with simplified
service state tables
CSTSWG colleagues ---
At the Berlin meeting, I was assigned action item #02-0511S: "JP to
provide the revised version of Annex E, describing the approach for
flagging the active state of started and acknowledged Prime Procedure to
the Association Control Procedure."
Actually, this action item is slightly misstated. In response to action
item #06-1010F, I had devised an approach that eliminated the need to
distinguish between state machines of CSTSes with stateful prime
procedure instances that are stateful because they employ START and STOP
operations vs. being stateful because they use a three-phased
(acknowledged) operation. The technical note describing that approach
explained the changes needed in the state tables for the Association
Control procedure and the stateful procedures in the CSTSFW. The
technical note also identified the changes in the state tables of Annex
E (Service State Tables) but did not identify all changes in Annex E
(that is, the changes in the text of Annex E). Action item 02-0511S was
to provide the complete update to Annex E.
The resulting update to Annex E has been uploaded to the CCSDS CSTSWG
CWE Red-1 Framework Review May.2011 folder at URL
http://cwe.ccsds.org/css/docs/CSS-CSTS/CWE%20Private/CSTS%20Framework%20
and%20Concept/Red-1%20Framework%20Review%20May.2011/SimplifiedStatefulAn
nexE.zip
The zip file contains two documents. The Word document "921x1r2[Draft
201012]-stateful-110601.doc" is a marked-up version of the December 2010
Red book with Annex E updated. The PDF file "921x1r2[Draft
201012]-Annex_E-clean.pdf" is a final printing of Annex E with all
changes accepted.
I believe that the revised Annex E is complete, with one exception: the
state tables for the stateless and stateful services use the incoming
event 'not authenticated PDU', the reference for which is given as
section 3.2.3.6. I believe that the definition of this event and the
composition of 3.2.3.6 may have been altered based on our discussions of
valid/invalid PDUs and how and when they are detected. The final
agreed-to rewording of those sections need to be examined and the
reference of the 'not authenticated PDU' incoming events adjusted
accordingly. In any case, the reference to that event needs to be made
more complete - currently it just displays "a)".
Best regards,
John
================
GST IT DEPARMENT
================
WARNING
Please, dont open pdf files from unknown source.
Adobe confirms PDF zero-day attacks. Disable JavaScript now.
http://blogs.zdnet.com/security/?pQ19&tag=.e589
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20110830/fc276f41/attachment.htm
More information about the Css-csts
mailing list