Dear Mr. HÎnes,
Thank you for the clarifications. Now we see what you aimed at. In order to
address your concerns we propose the following changes to the text (for
complete details is the inline text).
1)
a) Corrected definition of Native Address (now using the term transport
address)
b) Corrected definition of Native IP Address
2) Deleted the last sentence in each of the last two paragraphs of Section
IP Multicast
3) Corrected the last sentence in Section IP Broadcast.
Avygdor Moise
----- Original Message -----
From: "Alfred HÎnes" <ah(_at_)TR-Sys(_dot_)de>
To: <avy(_at_)fdos(_dot_)ca>
Cc: <draft-c1222-transport-over-ip(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org>;
<ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, November 02, 2010 7:35 PM
Subject: Re: draft-c1222-transport-over-ip-07 -- more concerns
Dear Mr. HÎnes,
I have queued a document that contains the STRICTLY EDITORIAL corrections
documented below for the RFC Editor.
I did not submit the document yet, because I am waiting for instructions
from the RFC Editor regarding these late comments.
Thanks for your efforts and elaborations.
At this instant, I only would like to give a short clarifying response
to a few details where I believe that you have misunderstood me.
[...]
(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. [...]
Actually no. The original text is exacly right.
This cannot be right.
A phrase like "The term XXX Address _is_ an YYY address ..."
is nonsensical, independent of technical intent; a _term_ (as used
here) never *is* an _address_, it only can *denote* an address.
> Native Address is a Definition in this RFC and used by C12.22.
That's correct from a general view of the C12.22 layer(s), but the
definition in Section 1.2 says "Native Address" is a *network*
address, whereas from the subsequent text it becomes clear that
with "Native IP Address" you want to designate a *transport* address,
that is the triple consisting of an IP address, a selector for the
transport protocol, and the transport protocol port number at that IP
address (with default values for protocol and port that can be omitted).
"Transport address", or colloquially, "socket" is the standing term in
the IETF to designate the communication endpoint where an application
(protocol) interfaces with the standard Internet Protocol suite,
and it should be your goal to map the generic term from C12.22 to the
established Internet terminology that you want to make use of, isn't it?
> Native IP Address is also a Definition in this RFC that scopes its
> use to an IP Network.
But in this paragraph that aims at introducing this term, you can't
also use it on the RHS of the definition, or it will become recursive
and thus not useful. And yes, in the scope of an IP network you need
a "transport address" for an application endpoint.
Maybe the problem is that the term "network" has a generic, layer-
agnostic meaning and a specific meaning: the IP layer bridging the
underlying subnetworks (physical and virtual link layers).
When used in combination with "address", IETF participants and most
RFC readers will assume the latter meaning; but that's not what I
assume that you want to do here.
1) Changed the definition of Native Address
from
"Native Address
The term Native Address refers to the network address that may be
used to reach a C12.22 Node on its C12.22 Network Segment [1]. In
this specification the Native Address refers to the Native IP
Address."
to
"Native Address
The term Native Address refers to the transport address that may be
used to reach a C12.22 Node on its C12.22 Network Segment [1]. In
this specification the Native Address refers to the Native IP
Address."
2) Changed the first sentence in the definition of Native IP Address
from
"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."
to
"The term Native IP Address denotes a Native Address that MAY be used to
reach a C12.22 Node on its C12.22 IP Network Segment"
[...]
(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.
Although I agree with you, this was introduced by another DISCUSS.
See RFC 2365 on Administratively Scoped IP Multicast.
IIRC, that is based on counting TTL to 0 or address scope recognition,
not on ensuring a lower bound on the TTL in packets being forwarded.
NB: Routers typically are not aware of the transport protocol port
usage and therefore, even if they implemented the mechanism suggested
in the document, would not know to which packets this rule needs to be
applied.
The practice in this area is not very clear or clean.
Agreed.
Relying on such router behavior will, at best, severely impede the
deployment of your proposal.
Deleted the last sentence in 2nd to last paragraph of Section IP Multicast
"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"
.
also deleted the last sentence in last paragraph of Section IP Multicast
"A
C12.22 IPv4 Relay SHOULD use a TTL that exceeds the threshold for any
C12.22 message destined for the global Internet."
(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.
The RFC does not have a position and does not encourage the use of
IPv6 nor IPv4. It does not care.
The RFC simply documents the encoding when used.
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.
The source and the means by which the knowledge can be obtained was
intentionally omitted.
This is a system implementation / operating system specific concern.
How it is handled internally by the software/firmware is outside the
scope
of the RFC.
See BCP 34 for the reasoning why directed broadcast has essentially
become moot since CIDR has been introduced. It only could make sense
inside a tightly controlled management domain, but it simply will not
work (any more) on the Internet.
See correction below
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.
This RFC does not recommend the use of broadcast. It recommends the
use of multicast.
It has proven a good principle of protocol design to not introduce
brittle mechanisms that are not expected to be useful, ab initio.
So my stance is that adding complications to implementations that
only make (very limited) sense in the IPv4 world does not buy.
Corrected the last sentence in Section IP Broadcast
from:
" This specification, however, does not preclude the use of
IP network directed or limited/local scope (address 255.255.255.255)
broadcast, and specifies a minimum requirement in Section 4.8,
Encoding of Multicast and Broadcast Addresses."
to
"This specification, however, does not preclude the use of
IP network directed or limited/local scope (address 255.255.255.255)
broadcast within a controlled management domain (as per RFC 2644 [19])"
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.
This RFC documents existing implementations and describes what is
being done and how it is encoded.
It tried very hard to remain in that realm.
There's no need to specify *all* features of existing implementations
in such a document if it's clear that these are of very questionable
utility and subsequent implementation would be simplified and furthered
by leaving out these additional unnecessary complications.
AMI Implementations have a very long time span and very poor documentation.
The nature of the Utility AMI business is such that it requires
documentation past, present and future.
I hope that we do let this minor difference of opinion be a stumbling block
in the publication of this RFC.
(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.
At first glance I was tempted to say that you are correct about the
interpretation of no "T" field in Figure 2.
However, the absence of the "T" (as documented in Section 2.3 "... or not
set (absent) for both UDP+TCP transports") should be interpreted as "any
of
TCP or UDP as appropriate".
In the case of sending a unicast APDU then if the target supports TCP and
UDP and then the originator may use TCP or UDP to push the message.
In the case of sending a multicast APDU then if the target supports TCP
and
UDP and the message should use UDP (of course) to send the multicast
message.
The responses, however, come back as unicast in accordance with the rules
stated in this RFC and the T flag.
Clearly if one wishes to communicate using TCP and via Multicast they
should
go back to school.
Also However, getting rid of Broadcast is going too far.
Why? Using the allocated multicast addresses is functionally
equivalent to broadcast in the domain where it is expected to
work in IPv4: on-link; so you wouldn't use any functionality,
and you have no choice of multicast in IPv6. So why unnecessarily
implement feature use specific to IPv4 at the *application* layer
that will not work any more in IPv6, which is the only feasible
environment for such project with the huge count of expected
network nodes.
Furthermore, in switched Ethernet fabrics (with IGP/MLD snooping
switches), multicast is more efficient than link layer broadcast.
The simple answer to that is the existing implementations and existing
equipment use it.
There is still a need to support existing (legacy) systems that use
broadcast. Therefore we included it as part of the possible encodings.
There are scenarios where broadcast works where multicast does not (again
anything can be made to work at some equipment replacement cost).
[...]
(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.
Your concern was reviewed and considered and addressed already in the
RFC.
In peer-to-peer communication between IP Nodes port randomization is
allowed in this RFC (see section "TCP and UDP Port Use"
item 5. "When the target UDP C12.22 IP Node is reachable using direct
messaging (as defined in [1] the C12.22 IP Node MAY set the
source port number to a UDP port number that is different than its
registered port number".
However C12.22 can and will span across non IP Network Segments. In this
case using source port randomization can and will break the larger C12.22
Network.
i.e. The span of the Smart Grid and C12.22 is greater than just the IP
Network.
Maybe I'm missing something; but by your definition and usage of the
encoding of "native IP addresses" you already have the base to handle
arbitrary source addresses of peers performing active open.
Simply (re-)use these transport associations once they have been
established.
I'd suggest that you take a look at how this has been solved in BGP-4
when the specification has been updated to RFC 4271 -- the predecessor
had similar preferences to fixed port numbers and was the subject of
serious concerns. Similarly, RFC 5452 clearly says "don't use port 53
with DNS active open, use random port numbers" (it doesn't use that
former term, but it says the same in other words).
I believe that you are missing something.
Arbitrary source IP ports will only work in the context of an C12.22 Node
Associations where both C12.2 Nodes reside on the IP Network and they do not
utilize a C12.22 Relay.
If a C12.22 Relay gets involved then things will break.
This RFC permits the use of random source ports where applicable and where
possible. Saying it otherwise will break ANSI C12.22 Standard.
[...]
Many Many Thanks for your input.
Avy
</snip>
Thanks for your cooperation and responsiveness as well,
even in this unusually late stage!
Kind regards,
Alfred HÎnes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf