|
Re: draft-c1222-transport-over-ip-07 -- more concerns
2010-11-03 18:04:54
We shall review the issues identified below and provide editorial
corrections.
We have two questions:
1) The subject line categorizes the concerns below as "-- more
concerns". Are there any other concerns that we are not aware of or that
were not brought to our attention since the upload of
draft-c1222-transport-over-ip-07? if so, were are they listed?
2) Should the revised document that addresses the concerns below be
uploaded as draft-c1222-transport-over-ip-08? or should it be mailed
directly to the editor?
Thank you
Avygdor Moise
On 11/02/2010 08:46 AM, Alfred � wrote:
Hello,
the recent discussion on draft-c1222-transport-over-ip-07
(regarding the clarification of the role of this specification)
has also caused me to take a closer look at the draft text.
(Unfortunately, I had not found the time to complete my review
earlier and send comments.)
I strongly suggest to address the observations below:
(A) General, recurring
(A.1)
The most striking editorial flaw I found repeatedly is the
annoying use of partial double-half-expansions of common acronyms,
like "UDP protocol", where the "P" in the abbreviation already
stands for "protocol".
(A.2)
Further, I'm confused a bit about the ISO terms. I'm almost a
layman in this respect, but as far as I undedstand the ISO OSI
stack, ACSE (Association Control Service Element) is part of the
ISO *session* layer. Therefore, the equivalence (postulated in
Section 1.1) of ACSE PDU and APDU (== Application Protocol Data Unit)
seems very surprising. Maybe this can be clarified / resolved.
Do you want to say that Session, Presentation, and Application Layer
are collapsed to a single layer in the C12.22 model? Then please
make that explicit. Otherwise, a lot of language in the memo is
confusing, as it mixes Session Control and Application data terms.
(A.3)
Due to the well-known expected addressing requirements for the
deployment of the subject protocol, I'm surprised of the lack of
strong preference towards IPv6. IMHO, the memo should recommend
that no significant deployments should be performed using IPv4.
See also items (B.10) and (B.11) below for things that are
architecturally insane and represent obstacles and/or unnecessary
overhead in the migration to IPv6.
(B) Sepcific
Here's a more complete list of specific remarks (in textual order of
first occurrrence); the item headlines contain a classification as
"nit", "concern", or "major concern".
(B.1) Section 1, 2nd para -- minor concern
The draft says:
ANSI C12.22, which is an application-level messaging protocol, may be
transported over any underlying transport network. This RFC defines
the requirements governing the transmission of ANSI C12.22 Messages
| via the TCP and UDP transports and the IP networking protocol.
The last line seems to be inbalanced in style, and it contains such
unpleasant partial expansion. Suggestion for better wording:
ANSI C12.22, which is an application-level messaging protocol, may be
transported over any underlying transport network. This RFC defines
the requirements governing the transmission of ANSI C12.22 Messages
| via the TCP and UDP transports in IP networks.
(B.2) Section 1.2 -- general (multiple instances) -- concern
Please replace phrases like "the UDP protocol" by either
"the User Datagram Protocol (UDP)" or simply "UDP";
(same for "the TCP protocol", "the IP protocol").
(B.3) Section 1.2 -- APDU and ACSE PDU -- concern
Please clarify as indicated above in (B).
(B.4) Section 1.2 -- C12.22 [Request/Response] Message definitions -- concern
Given the definition of "C12.22 Message" as being an APDU carrying
either a fully assembled, or a segment of, C12.22 Request Message
of C12.22 Response Message, the term "C12.22 Message APDU" for a
C12.22 Response Message does not make sense. The preceding
definition of "C12.22 Request Message" uses "C12.22 APDU".
The definitions as presented are circular. At one stage,
C12.22 Request/Response Messages are said to be an APDU,
but later the draft says that the latter *contain* an ACSE
that includes an EPSEM service request/response.
EPSEM is synonymous for C12.22 here, isn't it?
This confusion is also related to (B).
(B.5) Section 2.2, 1st para -- minor concern
The draft says:
| The term Native IP Address is a Native Address, which MAY be used to
| reach a C12.22 Node on its C12.22 IP Network Segment. The Native IP
Address includes the binary IP address, and an OPTIONAL port number
that MAY be followed by an OPTIONAL protocol identifier. The Native
IP Address SHALL be encoded as described in Section 2.3. Encoding of
Native IP Addresses.
The first sentence is highly confusing.
I suspect that you wanted to indicate:
vvvvvvv vvvvvvvvvvv vvvvvvvv
| The term Native IP Address denotes a transport address that can be
used to reach a C12.22 Node on its C12.22 IP Network Segment. [...]
(B.6) Section 2.3, 1st sentence in 1st para -- nit
... for storage in C12.19 Device Table.
should say:
... for storage in the C12.19 Device Table.
(B.7) Section 2.3, end of 3rd para -- nit
... using different ApTitle.
should say:
... using different ApTitles.
(B.8) Section 2.4, last para -- concern
The draft says:
Any IP firewalls or Access Control Lists (ACLs) shielding a C12.22
device MUST be configured to forward UDP and TCP traffic destined to
port 1153 and other ports that are assigned and registered by the
Network administrator, in order to maintain the continuity of the
C12.22 IP Network Segment.
This contains a significant, perhaps inappropriate asymmetry.
If ephemeral ports are used, wouldn't firewall rules / ACLs
also have to admit *return* traffic (originated from port 1153) ?
Of course, stateful filtering might be necesssary to discriminate
other port usage, and topological knowledge ('behind' which interface(s)
are listeners to port 1153 to be expected, and where only clients?)
will help to specify proper filtering rules.
Proposed text:
Any IP firewalls or Access Control Lists (ACLs) shielding a C12.22
| device MUST be configured to forward UDP and TCP traffic destined to,
| and originating from, port 1153 and other ports that are assigned and
registered by the Network administrator, in order to maintain the
continuity of the C12.22 IP Network Segment.
| The configuration will likely depend on the presence or absense of
| devices with asserted "accept" flag(s) (see Section 3.1).
(B.9) Section 2.6, 4th + 5th para -- nits
The placement of parentheses and a comma there should be adjusted.
4th para:
Any IPv6 C12.22 IP Node that supports IP multicast SHALL use
| Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14]
| possibly within ICMPv6 RFC 4443 [15]) to report membership.
---
Any IPv6 C12.22 IP Node that supports IP multicast SHALL use
| Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14])
v ^
| possibly within ICMPv6 (RFC 4443 [15]) to report membership.
or perhaps shorter:
Any IPv6 C12.22 IP Node that supports IP multicast SHALL use
| Multicast Listener Discovery version 2 (MLDv2) (RFC 3810 [14])
v ^
| to report membership.
And in the 5th para:
Routers that interconnect C12.22 IP Nodes on the C12.22 IP Network
| Segment, MUST support [...]
--- ^
Routers that interconnect C12.22 IP Nodes on the C12.22 IP Network
| Segment MUST support [...]
(B.10) Section 2.6, 2nd-to-last para -- major concern
The draft says:
In the implementation of this technique, an administrative domain
MUST include at least one C12.22 IP Relay, and all C12.22 IP Nodes in
the administrative domain SHOULD be configured with a TTL
| sufficiently large to reach that C12.22 IP Relay. A TTL threshold
| SHOULD be defined and configured on all border routers linking the
| administrative domain to the global Internet such that the routers
| forward on their Internet interfaces only those 224.0.2.4 multicast
| packets that have a TTL exceeding the threshold value.
This is an architecturally insane recommendation. Routers decrement the
TTL / Hop Count field on the "fast path" -- frequently with dedicated
hardware support. This protocol cannot expect to be successful in
requiring a new kind of TTL / Hop Count processing by major (boundary)
routers. The only property of TTL / Hop Count that routers should
remain interested in is whether it counts down to zero.
The GTSM (RFC 5082) purposely restricts checking of *lower* bounds
for TTL / Hop Count to the communicating end systems (notwithstanding
the case where the relevant end systems are routers themselves).
Therefore, IMHO the advice given here is not a good idea.
An application protocol should not request changes to on-path routers.
(B.11) Sections 2.7 and 2.8 -- major concern
Section 2.7 (and other parts of the memo) discuss, and seem to
encourage, the use of IPv4 network directed broadcast.
Since since the pervasive use of CIDR the prefix length of subnets
essentially only is known within confined administrative domains,
and knowledge of the addressing structure should not be imposed
on routers other than those at the prefix [de-]aggregation point
in the network topology, this seems to be a ppor advice as well.
Section 2.8 of the draft says (4th paragraph):
The IPv4 network directed broadcast address can be computed by
performing a bitwise OR between the bit complement of the subnet mask
of the target IP subnet and the IP address of any host on that IP
subnet.
.... but it does not say where the knowledge of the subnet mask should
be derived from for non-local (i.e. other that on-link) subnets.
Note that 11 years ago, RFC 2644 (BCP 34) has changed the default
for router support of directed broadcast; it also says:
Network service providers and corporate network operators are urged
to ensure their networks are not susceptible to directed broadcast
packets originating outside their networks.
Thus, it looks like Internet-wide use of directed broadcast cannot
be achieved anyway. Recommending its use does not make sense for
new applications.
Furthermore, IMO the document should be much more aware of IPv6
and not recommend to explore niches of IPv4 no more present in IPv6;
therefore, I'd strongly suggest to drop broadcast support entirely
from the document. IP multicast, if properly used, offers scoping
with architectured mechanisms.
(B.12) Section 2.8, Figure 2 -- major concern
The whole figure seems to be misleading and overly complicated.
Most likely the changes applied to arrive at the current Section 2.3
have been applied thoughtlessly as well:
IP Multicast and Broadcast does not support connection-oriented
transport. Thus, in this case, the only possible transport protocol
supported by this specification is UDP.
However, according to the 1st para of Section 2.3, an absent "T"
element in the Native Address encoding means TCP _and_ UDP !
Thus, for conformance with Section 2.3, the 6 variants (of 9)
in Figure 2 that do not contain the "T" field are inappropriate
and should be deleted entirely.
Getting rid of IPv4 Broadcast (as recommended above) will drop the
first remaining choice as well and leave a single representation
each for IPv4 and IPv6.
(B.13) Section 3.1, 3rd para (above Table 1) -- concern
The text there seems to be confusing.
I suggest to clarify it by changing:
| The mapping of the connection-type parameters to the type of TCP and
| UDP transports that a C12.22 Node MAY support is defined in Table 1.
---
| The mapping of the connection-type parameters to the type IP-based
vvvvvvvvvvvvvvvvvv ^^^^^^^^^
| transport variants that a C12.22 Node MAY support is defined in
Table 1.
(B.14) Section 3.1, Table 1 -- concern
The table should perhaps make better use of wildcard ('x') entries
for the "invalid" cases, not only in the first table row.
To this end, I suggest to group together the 4 subsequent such rows
and replace them with properly wildcarded versions:
0 1 1 0 Invalid
0 1 1 1 Invalid
---
0 x 1 x Invalid
and:
1 0 0 1 Invalid
1 0 1 1 Invalid
---
x 0 x 1 Invalid
Note: Essentially, the groups of the CL and CO related flags are
independent from each other, and an alternate representation of
the table would show the meanings of the CL and the CO related flags
in two distinct, short tables (with 4 rows each), with the additional
remark that, to be useful, at least one of the basic flags must be set
(this rule is currently represented by the first table row).
(B.15) Section 3.2.1 (ff.) -- major concern
The recommendations given there seem to be in conflict with
RFC-to-be 6056 (BCP 156) on Transport Protocol Port Randomization.
The recommendation given there in focor of the use of fixed port
numbers as far as possible opens an avenue for spoofing attacks.
In the past, the IETF has changed important, also symmetrically
behaving protocols -- most importantly: BCP-4 -- with regard to such
concerns, to get rid of the usage of a fixed port number on the side
of the peer performing the Active Open, and to use the connection,
once established, in a symmetrical manner, irrespective of the
asymmetry of port number usage in the underlying transport layer.
Similarly -- as an example for an UDP-based service -- the DNS
recommendations have been changed in favor of the use of randomized
source port numbers.
I do not see a necessity to weaken the protocol described here by
forcing it to once more use practices that have been recognized as
poor many years ago.
Thus, IMHO, Section 3.2.1 needs a deep reconsideration.
This extends to the rule in the last paragraph of Section 3.2.2
and a couple of other places in the text.
(B.16) Sections 3.3 and 3.4.1 -- major concern (recurring)
Again, I question the utility and applicability of the considerations
regarding network directed IPv4 broadcast, as explained above.
(B.17) Section 3.5 -- typo
... to send urgent messaged over IP.
--- ^
... to send urgent messages over IP.
Kind regards,
Alfred H�nes.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|