Re: [16NG] AD review of draft-ietf-16ng-ip-over-ethernet-over-802.16

Thanks for the careful review. I must admit, finding the appropriate
answers to some of the questions took longer than assumed. And we
started to restructure the I-D according to Jari's recommendation to get
an initial feeling about the dependencies in the text.

>This is only a preliminary version of my AD review, for a couple of 
>reasons. I had many questions, and I wanted to voice them as soon as 
>possible. I'm on vacation and didn't have enough time to go back and 
>look at the WG discussions for the rationale of various design 
>decisions, and since this e-mail is being written in an airplane, I did

>not have the possibility of calling the authors or chairs for 
>clarification. Finally, as the public network scenario in this document

>resembles DSL, I wanted to show this spec to my co-AD who is an expert 
>on DSL.

Getting a review from a DSL expert is welcome, even when the public
access model mentioned in the IPoETHo802.16 I-D is both a sub-set and an
extension of the DSL model; a sub-set because DSL deploys different
models up to putting each subscriber on its own link (VLAN), and an
extension because DSL has not yet fully covered the particularities of
supporting  IPv6 over Ethernet in the access.

>Overall, there are a number of issues or at least question marks. Not 
>surprisingly the part of this document that defines how to carry IP
over 
>Ethernet in 802.16 is in pretty good shape. But I do have multiple 
>concerns about the way that this draft handles some of the
optimizations 
>related to IP layer behavior. For instance, some of the filtering rules

>seem more appropriate as operational suggestions than parts of the 
>normative spec. There are inconsistencies with regards to IPv6 and 
>redirects need to be handled. The centralized bridge model does not 
>appear to be either necessary or sufficient to handle the task it was 
>designed for.

Your comments are valid concerns and will be addressed in the next
revision of the document. But the main issue leading to the comments is
the mixture of different deployment scenarios throughout the document.
It is not easy to follow which of the statements are relevant for which
of the deployment models. Furthermore the predominant deployment model
'Public Access' is a special case of the generic 'Enterprise LAN' model.

>Why was RFC 4605 used instead of RFC 4541?

RFC 4541 is Informational, RFC 4605 is Standards Path. Making normative
references to an Informational document is not appropriate, even if it
would have been simpler. Being able to make normative references to RFC
4541 would make our task much easier.

>What can this spec mandate about the behavior of hosts connected 
>via a regular Ethernet and a bridge to the 802.16 network?

The spec can only mandate that the hosts connected to the Ethernet are
following the generic specifications like RFC 894 and RFC 2464 for IP
over Ethernet. And the spec has to mandate that the Ethernet over 802.16
does behave like standard Ethernet, e.g. does not introduce any
additional restrictions for the MTU size. Probably we missed to state
the prerequisite very clearly in the I-D.

>One discussion that we should have is what parts of the document are 
>operational advice on techniques that can be employed to reduce extra 
>traffic, and what parts are fundamental parts of IP over
802.16/Ethernet 
>without which no interoperability can be achieved.

Fundamental parts are using 'MUST' statements, while operational advise
is usually marked by 'SHOULD' statements. And operational hints are
provided in two layers; hints for the generic deployment model and
special hints for the public access scenario.
The I-D adopted a functional approach and listed the operational hints
for the generic case and the special case directly following the
introduction of the function. We found that this mixture of generic case
and special case is not working well, and a structure where all the
generic statements are kept together clearly separated from the special
statements for public access scenario may be much better to follow.

We will change the structure of the I-D and split out all the special
requirements for the public access scenario in a dedicated section after
introducing the generic case. The new structure may look like:
- Mandatory requirements for interoperability
- Optimizations for the generic deployment case
- Recommendations for the public access scenarios
It looks that such a structure can be introduced with just shuffling
around the chapters of the document with some new text necessary for the
description of the public access scenario.

>Detailed comments below.
>
>Technical:
>
>> Those IP specific support
>> functions are preferably realized in a centralized device containing
>> a bridge for aggregation of traffic from all the BSs to provide a
>> more straightforward management solution and allow for effectively
>> commoditized BSs, which may be deployed in the IEEE 802.16 based
>> access network in a large volume.
>> The IEEE 802.16 Ethernet
>> link model MUST interconnect each point-to-point connections assigned
>> to SSs at a centralized point, a.k.a. network-side bridge, as shown
>> in Figure 2.  This is equivalent to today's switched Ethernet with
>> twisted pair wires connecting the hosts to a bridge ("Switch").  The
>> single and centralized network-side bridge allows best control of the
>> broadcasting forwarding behavior and prevents potential security
>> threats coming up with cascaded bridges.
>
>This appears to be an implementation consideration this is
inappropriate 
>for an IETF IP over Foo specification. (See also below on my comments
on 
>Appendix B.)

It looks like an implementation consideration, but it is not. As
mentioned in both, the first sentence taken from the introduction and
the later sentence in the second paragraph, there is functional reason
to collocate all the forwarding decisions of a switched LAN (bridging
function) in a single device.
The real issue with the statement above is the 'centralized point'. Such
wording is inappropriate for a MUST requirement.
I would propose to rephrase the sentence into:
"The IEEE 802.16 Ethernet link model MUST interconnect each
point-to-point connections assigned to SSs by a network-side bridging
function, as shown in Figure 2."

>>    IEEE 802.16g [802.16g] defines a GPCS (Generic Packet Convergence
>>    Sublayer), which may be used to transfer Ethernet frames over IEEE
>>    802.16 as well.
>
>s/may be used to transfer/may be used by future specifications to
define 
>how to transfer/
There is no need for future specifications to deploy GPCS for
IPoETHo802.16. GPCS can be used for transferring ETH frames as well as
native IP packets (as well as PPP and MPLS) over 802.16. When carrying
Ethernet, GPCS is interoperable with ETH CS as it uses the same packet
formats over the air as ETH CS. The difference is the non-existence of
classification rules for GPCS, i.e. it is not defined by IEEE802.16 by
which filtering of packet headers payload packets are assigned to
particular service flows.
IMHO, the proposed change is not appropriate.

>> In the Public Access scenario, direct communication between nodes is
>> restricted because of security and accounting issues.
>
>And presumably mere volume of traffic as well?

What is the thinking behind this statement? Traffic volume is usually
not an issue when the operator is able to charge for it. Enforcing that
all traffic is passing through the control point of the operator ensures
that all packets are accounted.

>> 6.1.1. Public Access Scenario Case
>>
>> The network-side bridge SHOULD forward all packets received from any
>> lower side ports to all upper side ports being in the forwarding
>> state.  Direct communication between SSs SHOULD NOT be supported by
>> the network-side bridge and all packets sent from a SS to the BS
>> SHOULD be delivered to an AR.
>
>The document comes across as a very system oriented. This is unusual
for 
>an IETF IP over Foo specification, and I suspect that over time we'll 
>regret too tight bindings to particular deployment situations. I think 
>the spec would be better recast as a the key IP over 802.16/Ethernet, 
>followed by a set of recommendations for different situations. You can 
>even specify cleanly separated optional functions (such as preventing 
>direct communication) that deployers can choose to use in a particular 
>situation.

I am not sure about the meaning of the comment. What is 'very system
oriented' in the sentence above? That forwarding of IP packets is
performed by a router and not by multipoint-to-multipoint L2
connectivity. Interestingly the desired Ethernet behavior for public
access is resembling the behavior of the unique prefix per MS of the
plain IP solution.
Nevertheless I assume that the description will fit much better into the
'Recommendations for public access' part of the new structure.

>> All multicast and multicast control messages SHOULD be processed in
>> the network-side bridge according to [RFC4605].
>I would like to understand the decision to use 4605 instead of 4541 
>which seems more suited to bridged environment.

RFC 4541 is Informational. RFC 4605 is Standard. Making normative
statements to Informational RFCs looked not appropriate to us.

>> The IEEE 802.16 Ethernet link model in Section 5.1 has a basic tree
>> topology and [RFC4541] provides an application guide how bridge,
>> non-IP device, to examine and learn group membership.  Hence,
>> [RFC4605] can be applied to the IEEE 802.16 Ethernet link model to
>> reduce the multicast packet flooding.
>>
>> The network-side bridge in the IEEE 802.16 Ethernet link model SHOULD
>> play a role in proxying IGMP/MLD messages as specified in [RFC4605].
>> The network-side bridge SHOULD perform the host portion of IGMP/MLD
>> process on its upper side port and the router portion of IGMP/MLD
>> process on its all lower side ports.
>
>I do not understand how the first paragraph can state that bridges are 
>non-IP devices and then the second paragraph goes on to talk about the 
>application of IP layer processes such as acting as a host.

Agreed. The challenge is to define a system by normative statements
based on RFC 4605 to resemble the behavior of RFC 4541. The most easy
solution would be a normative statement to RFC 4541, but this is
inappropriate for a standards path document (?). So we will tweak the
text to get this ambiguity removed. Some more text may help.

>> The network-side bridge in the IEEE 802.16 Ethernet link model SHOULD
>> discard all IP broadcast packets except ARP, DHCP (DHCPv4 and
>> DHCPv6), IGMP, and MLD related traffic.  The ARP, DHCP, IGMP and MLD
>> related packets SHOULD be forwarded with special rules specified in
>> this specification.
>This is inappropriate. First, you stated earlier that this Section
(6.3) 
>also applies to the enterprise deployment. In that environment, turning

>off broadcast may be inappropriate.

You are right, and thanks for pointing to this mistake. We will revise
the text to ensure that broadcast is not impacted for the generic case
(Enterprise LAN scenario).

>Secondly, i think you are mixing the specification of IP over Foo with
a 
>particular filtering requirement in a specific deployment. Its fine to 
>state operational advice, but do not cast it as a part of the normative

>specification.

The distinction between normative requirements and operational hints
should be much clearer in the new structure. But where is the border
line? Is usage of MLD snooping an operational hint or a normative
recommendation to make the system working?

>> Note that packets destined for permanently
>> assigned multicast addresses such as 224.0.0/24 in IPv4 or FF02::1 in
>> IPv6 are also regarded as broadcast data.
>All permanently assigned addresses? Even all-routers, for instance? Be 
>more specific.

Thanks for showing the shortage. We will provide a more comprehensive
description.

>> 6.4. Proxy ARP
>>
>> Proxy ARP provides a process where a device on the link between hosts
>> answers ARP Requests instead of the remote host.  In this
>> specification, the Proxy ARP mechanism is used to force all traffic
>> from hosts to the access router or to avoid broadcasting ARP Requests
>> over the air depending on the particular deployment scenario.  The
>> Proxy ARP process is usually co-located with the network-side bridge.
>Another part of the specification that should be cast as an operational

>advice of other techniques that can be used to combat excessive
traffic? 
>Please consider a separate section for these.

Agreed. There is a mode of operation of Proxy ARP, which is applicable
to all scenarios, and there is a special treatment of Proxy ARP in the
public access scenario. We will separate the two aspects in different
sections.

>> In the public access scenario, all packets between SSs will always be
>> relayed via access router.  In this scenario, the access router
>> SHOULD forward packets via the same interface on which the access
>> router received the packets, if the source and destination addresses
>> are reachable on the same interface.  This would result in a Redirect
>> message from the access router [RFC0792][RFC4861].  The Redirect
>> message MUST be suppressed.
>> 8.1. Public Access Scenario Case
>>
>> Unique IPv6 prefix per SS SHOULD be assigned because it results in
>> layer 3 separation between SSs and it forces all packets from SSs to
>> be transferred to an AR. 
>If we are employing per-SS prefixes, what is the point of the Redirect 
>discussion above?

Usually the ICMP redirect function is implemented such that a ICMP
redirect  
message is issued when packets are forwarded via a incoming interface.
This requirement is copied from Req#179 in TR 101 (Migration to
Ethernet-Based DSL Aggregation) to make the behavior consistent with
widely deployed public access networks.

>> In this
>> specification, SSs perform above the discovery process by solicited
>> Router Advertisement messages because periodic Router Advertisement
>> messages are discarded on the network-side bridge following the
>> Broadcast Data Forwarding Rules in Section 6.1.2.
>
>Hmm. Given that there can be regular Ethernet bridges and 802.16
unaware 
>hosts at the subscriber side, where does that leave hosts that are 
>relying on RAs? (E.g., hosts complying with RFC 3775.)

Thanks for bringing this up. We will add

>> 9.2.2. Address Configuration
>> SS SHOULD derive its global IPv6 addresses based on prefix and EUI-
>> 64-derived interface identifier
>
>And similar other sections.
>
>Again, given that this must work with regular Ethernet-attached hosts, 
>to what extent are these statements useful?

Normative language is not appropriate in this section, but it may be
helpful to explain what is expected from hosts attached to the Ethernet.

>Also, this document should not make any recommendations on what 
>particular address assignment mechanism should be employed (4862, 3041,

>etc).

Agreed. We will take it into account when revising the text.

>>    The Proxy ARP function described in Section 6.4 prevents that ARP
>>    broadcast messages have to be forwarded to each of the associated
>>    SSs, when the ARP proxy is aware of the existence of the queried
IP
>>    address at one of the bridge ports.  If the queried IP address is
not
>>    known to the ARP proxy, the bridge has to flood all its ports with
>>    the ARP request.
>>
>>    Distributing the bridging function into the BSs would imply that
the
>>    Proxy ARP function is split into multiple Proxy ARP functions each
>>    knowing only about the subset of the IP addresses, which are
directly
>>    connected by the BS.  IP addresses belonging to the same link but
>>    being connected to other BSs would not be known to the Proxy ARP
>>    functions and would cause ARP requests for these IP addresses to
be
>>    broadcast to all SSs.  This causes a waste of radio resources for
>>    transmitting ARP requests and potentially more critical even, it
>>    would waste scarce battery power in the SSs.
>>
>>    A malicious user would be able to deploy this behavior for denial
of
>>    service attacks by exhausting the batteries of SSs by sending
>>    malicious ARP Requests.
>
>First, the same malicious user can employ the same technique and still 
>cause denial-of-service via ARP requests. All that he has to do is to 
>select an address which is not on the link. According to your 
>explanation above, this would be flooded to every port.

You are right, this text is buggy. Malicious ARP requests cant be
defended just by a concentrated bridging function.

>Second, if you really wanted to make this work, wouldn't flooding only 
>to the upstream port achieve what you want to do, without requiring one

>centralized device?

What do you mean with flooding only to the upstream port? Do you assume
that there is a centralized Proxy ARP function located in the AR?
In the generic case there is no upstream port, the AR may reside on any
of the port. The preference for a centralized bridging function arises
out of the more generic Enterprise LAN scenario, where no indication is
available about the position of the AR. Indeed there is not much
difference between concentrated and distributed bridging for the public
access scenario.

>Editorial:
>
>Term PKM used before expanded or introduced.

Will be covered in the revision.

>> The IEEE 802.16 standards define a packet CS (Convergence Sublayer)
>> for interfacing with all packet-based protocols.  IEEE 802.16g
>> [802.16g], also, specifies a generic packet CS to provide an upper-
>> layer protocol independent interface.  This document describes
>> transmission of IPv4 over Ethernet as well as IPv6 over Ethernet via
>> the CSs in the IEEE 802.16 based access network.
>This paragraph is confusing. I cannot tell what CS you are using. I 
>think you are using the Ethernet CS, but the paragraph fails to mention

>this.

Either of them works. But we will add some more text to this paragraph.

>> forwarding of packets over the air is performed
>> only on base of the CID value
>s/base/based/
>
>> This is beneficial when Ethernet frames with arbitrary
>> MAC addresses have to be forwarded to a SS in the case that the SS is
>> interconnected to another network.
>
>s/.../This is required for bridging./
>
>> This document does not introduce new vulnerability to operations of
>
>any new vulnerabilities?
>
>the operations?
>
>>    services suffers from several following drawbacks.
>from the following drawbacks

Thanks for the editorial hints. We will adopt them to the next revision.

Bye
Max
_______________________________________________
16NG mailing list
16NG@ietf.org
https://www.ietf.org/mailman/listinfo/16ng