Title: ULCS/SV2 - Padding embedded ATN ASE APDUs 
PDR Reference:              M1060001 
Originator Reference: 
SARPs Document Reference:   SV4, SV2 
Status:                     ADOPTED (not done for SV2) 
Impact:                     A (for security encoding changes) 
PDR Revision Date:          30/01/02 (RESOLVED -> ADOPTED)
				     23/08/01 (PROPOSED -> RESOLVED) 
                            09/08/01 (revised after comments)  
                            02/08/01 (minor editorial changes) 
                            12/07/01 (ACCEPTED -> PROPOSED) 
                            19/06/01 (SUBMITTED -> ACCEPTED) 
PDR Submission Date:           12/06/01 
Submitting State/Organisation: ACI 
Submitting Author Name:        Rozenblum, J. 
Submitting Author E-mail Address: rozenblum@tlse.sofreavia.fr 
Submitting Author Supplemental Contact Information: 
SARPs Date:                    DOC 9705 edition 2 and edition 3 
SARPs Language:                English 
Summary of Defect: 

ATN end system interoperability problems are experienced because the ATN 
SARPs do not indicate whether padding bits must be added at the end of the 
ASE APDUs (e.g. ATN-App, ACSE, SESE) when the resulting encoding is not a 
multiple of 8 bits. 

Assigned SME:                  SME 4, SME2 and SME3 


SME Analysis: 

It is clear that the SARPs are open to interpretation in the area of 
encoding embedded ASN.1 BIT STRINGs, as the PDR was raised following 
a failure to interoperate between air and ground applications.  The 
problem concerns whether or not there should be padding bits in PER 
encoded bitstrings that are embedded in other ASN.1 types.  The 
problem manifests itself only as a bitcount value that is greater 
than the number of significant bits in the encoded value, since the 
bitstrings in question are always at the end of the overall encoding, 
which is anyway padded with zeroes to an octet boundary. 
Implementations that perform a strict check on the received bitcount 
therefore encounter an error if the sender added padding bits that the 
receiver did not expect (or if the sender did not add padding bits that 
the receiver DID expect). 

There are a number of 'givens': 
- the intention has always been for the minimum number of bits to be sent 
over the air-ground data link.  This intention is embodied in the encoding 
examples in guidance material (Doc 9739/1, Part IV section 2.7), which show 
that intermediate padding bits are NOT present in the encodings. 
- a canonical (i.e. reproducible) encoding is preferred to avoid possible 
problems (e.g. with security services, new compression algorithms, 
certification requirements for predictable behaviour, etc.) in the future 
* therefore it is better not to allow a choice between arbitrary and 
single-ASN1-type (though it may be necessary to live with both, and include 
a SARPs Recommendation to use bitstring), 
* and *optional* padding bits cannot be allowed (because there could be 
different encoded length values, hence non-canonical) 
- it has to be accepted that ATN SARPs not completely conformant to 
external OSI standards, including ACSE and PER standards. 
- ATN applications are 'special' because all protocol elements are 
collapsed into a single abstract syntax. 

There has been considerable email debate on this PDR - the technical 
arguments are captured in CENA archive file 
atnp/ccb/sme4/m1060001_discussion.zip. 


Proposed SARPs amendment: 

SUB-VOLUME IV CHANGES 
===================== 

1/INSERT a new subsection and Note after 4.3.2.6.4: 

4.3.2.6.4 bis   A bit-oriented encoding shall be applied, such that no 
padding bits are appended to the encoded BIT STRING value, and the 
length determinant of the BIT STRING encoding equates to the number of 
significant bits. 

Note.- The above provision means that data encoded by ATN ASEs, when 
embedded in presentation-data-values, are treated by the CF as normal BIT 
STRING values, not in general an integral number of octets. Padding to an  
octet boundary only applies to the outermost Fully-encoded-data value that 
is passed across the Presentation Service boundary. 


2/ INSERT a new subsection 4.3.2.6.8 and Notes: 

4.3.2.6.8   Between peer ATN-App AEs, a single default presentation 
context shall be used; this is known by bilateral agreement. 

Note 1.-  All component abstract syntax modules (e.g. ATN-App-ASE, ACSE, 
SESE) are considered merged into one.  It is the job of the CF to merge  
and split contexts, since ATN does not use presentation layer context  
handling services. 

Note 2.- ASN.1 packed encoding rules, basic unaligned variant, are used 
to provide the transfer syntax for the single abstract syntax. 

Note 3.- Clause 7.9 of the PER Standard is not applicable to ATN, since: 
a) EXTERNAL values are fully resolved since all abstract syntaxes are 
known a priori, 
b) when carried in the (null) presentation protocol, 'full encoding' 
with the BIT STRING choice alternative is used. 

Note 4.- The 'outermost value' referred to in Clause 10.1.1 of the PER 
Standard is interpreted in ATN context as the encoded data that passes 
over the Presentation Service boundary.  Padding bits are appended to 
achieve octet alignment at this boundary. 


3/INSERT a new Note after 4.6.4.2.3: 
Note.- When embedded in Fully-encoded-data at the Presentation Service 
boundary, encoded ACSE APDUs are treated as bit-oriented values that are 
not padded to an integral number of octets; the length determinant includes 
only the significant bits of the encoding, corresponding to the ASN.1 type. 


4/  In 4.6.6.3.2.1, Table 4.6-15: 
Row A.A.11.2/1 (GraphicString), column ATN Support (1),  
  REPLACE: See text WITH: X 
Row A.A.11.2/1 (GraphicString), column ATN Support (2),  
  REPLACE: M WITH: N/A 
Row A.A.11.2/2 (BIT STRING), column ATN Support (1),  
  REPLACE: See text WITH: M 
Row A.A.11.3/3 (EXTERNAL), column ATN Support (1),  
  REPLACE: See text WITH: X 
Row A.A.11.3/3 (EXTERNAL), column ATN Support (2),  
  REPLACE: M WITH: N/A 


5/ In 4.6.6.3.2.2, REPLACE: 
If the authentication functional unit is supported, at least one of 
the Authentication-value forms listed in Table 4.6-15 shall be 
implemented for sending. 
WITH: 
If the authentication functional unit is supported, the BIT STRING  
form of encoding the ACSE Authentication-value field shall be used, 
with a bit-oriented encoding such that no additional padding bits 
are appended to the encoded value. 

Note.- The above provision means that data values encoded by SESE, 
when embedded in ACSE APDUs, are treated by the CF as normal BIT 
STRING values, not in general an integral number of octets. Padding 
to an octet boundary only applies to the outermost Fully-encoded 
-data value that is passed across the Presentation Service boundary. 


6/ In 4.6.6.3.3.2, INSERT new subsections and Notes after Table 
4.6-17, as follows: 

4.6.6.3.3.2.2   Recommendation.- The arbitrary form of encoding ACSE 
user-information should be used. 

Note.- The above Recommendation, if followed, produces a canonical 
encoding for a given user PDU, is consistent with the Fully-encoded 
-data wrapper used by the CF at the Presentation Service boundary, 
and provides optimal bit-efficiency. 

4.6.6.3.3.2.3    When the 'arbitrary' (BIT STRING) form of encoding is 
used, a bit-oriented encoding shall be applied, such that no additional 
padding bits are appended to the encoded BIT STRING value in the EXTERNAL 
user information type, nor to the encoded EXTERNAL value itself. 

Note.- The above provision means that data encoded by ATN-App ASEs, when 
embedded as user-information in ACSE APDUs, are treated by the CF as normal 
BIT STRING values, not in general an integral number of octets. Padding 
to an octet boundary only applies to the outermost Fully-encoded-data value 
that is passed across the Presentation Service boundary. 

4.6.6.3.3.2.4. If the 'single-ASN1-type' (ABSTRACT-SYNTAX.&Type) form of 
encoding is used, the octet-oriented encoding of an open type shall be 
applied, such that additional padding bits are appended to make the length 
of the encoding produced so far a multiple of eight bits. 

Note.- Encoding as single-ASN1-type is permitted for backward 
compatibility, but its use is deprecated. 


7/(edition 3 only) INSERT new subsections after 4.8.6.2.1.2: 
4.8.6.2.1.3    SESE APDUs shall be encoded as instances of the type 
SESEapdus specified in ISO/IEC 11586-3 | ITU-T Rec. X.832, including 
the encoding of the top level CHOICE. 

4.8.6.2.1.4    Encoded SESE APDUs shall be treated as bit-oriented 
values that are not padded to an integral number of octets; the length 
determinant includes only the significant bits of the encoding,  
corresponding to the ASN.1 type. 

4.8.6.2.1.5   Padding bits shall be appended if necessary to achieve 
octet alignment of encoded values in the following cases only: 
a) the 'unprotected' field in the ATNProtectSign type, which will 
be a bit-oriented ATN-App APDU value, padded to an integral number 
of octets. 
b) the open ASN.1 type seItem in the SESEapdus.SETransfer APDU, since 
the PER standard requires, in clause 10.2, that this is encoded as an 
octet-aligned-bit-field, preceded by an encoded length in units of 
octets. 


8/(edition 3 only) INSERT a new Note after 4.9.3.7.1: 
Note.- Encoded GACS APDUs are treated as bit-oriented values that are not 
padded to an integral number of octets; the length determinant includes 
only the significant bits of the encoding, corresponding to the ASN.1 type. 
The only exception to this, though not recommended, is if a GACS APDU is  
carried as user-information in an ACSE APDU, in which case it may be  
treated as an octet-aligned single-ASN1-type.  


SUB-VOLUME II CHANGES 
=====================* 

9/INSERT a new Note after 2.1.6.1.1: 
Note.- When encoded CM APDUs are treated as bit-oriented values that are 
not padded to an integral number of octets, the length determinant includes 
only the significant bits of the encoding, corresponding to the ASN.1 type. 

10/INSERT a new Note after 2.2.1.6.1.1: 
Note.- When encoded ADS APDUs are treated as bit-oriented values that are 
not padded to an integral number of octets, the length determinant includes 
only the significant bits of the encoding, corresponding to the ASN.1 type. 

11/INSERT a new Note after 2.2.2.6.1.1: 
Note.- When encoded ARF APDUs are treated as bit-oriented values that are 
not padded to an integral number of octets, the length determinant includes 
only the significant bits of the encoding, corresponding to the ASN.1 type. 

12/INSERT a new Note after 2.3.6.1.1: 
Note.- When encoded CPDLC APDUs are treated as bit-oriented values that are 
not padded to an integral number of octets, the length determinant includes 
only the significant bits of the encoding, corresponding to the ASN.1 type. 

13/INSERT a new Note after 2.4.6.1.1: 
Note.- When encoded FIS APDUs are treated as bit-oriented values that are 
not padded to an integral number of octets, the length determinant includes 
only the significant bits of the encoding, corresponding to the ASN.1 type. 


Impact on Interoperability: 

Decoding errors (and connection release) systematically occur when two 
communicating systems do not implement the same padding scheme and the 
receiving system checks the way the sender has encoded the message. In 
some cases, the length of the decoded data does not match the length 
of the encoded data. 

Some of the changes proposed for Security ASE encodings are non-interoperable 
(i.e. prohibiting previously legal encodings).  This is justified on the 
grounds that the security provisions have not yet been formally published 
by ICAO, and also that there are no known implementations to date. 


PDR Validation Status:      Validated by actual implementations. 

SME Recommendation to CCB:   

CCB Decision:               RESOLVED