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

From: Jari Arkko <[email-masked]>
Date: Mon, 30 Jun 2008 16:56:58 -0400

Hi all,

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.

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 behaviour. 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. Why was RFC 4605 used instead of RFC 4541? What can this 
spec mandate about the behaviour of hosts connected via a regular 
Ethernet and a bridge to the 802.16 network?

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.

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.)

>    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/

> 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?

> 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.

> 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.

> 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.

> 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.

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.

> 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.

> 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.

> 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?

> 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.)

> 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?

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

>    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 denia-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.

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?

Editorial:

Term PKM used before expanded or introduced.

> 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.

> 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

Jari

_______________________________________________
16NG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/16ng

---

From: "Daniel Park" <[email-masked]>
Date: Tue, 1 Jul 2008 12:10:43 +0900

Thanks Jari for your good comments on this deliverable,

I am expecting authors will clean up all of your comments at upcoming 16ng
F2F meeting. 1-hour is now reserved for our meeting, so I think 40 mins for
EthernetCS and 20 mins for IPv4CS at this meeting.

TO: Max and Samita, please remind your talking length...

Daniel Park (on behalf of 16ng WG)

On 7/1/08, Jari Arkko <[email-masked]> wrote:
> 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.
>
> 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 behaviour. 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. Why was RFC 4605 used
> instead of RFC 4541? What can this spec mandate about the behaviour of hosts
> connected via a regular Ethernet and a bridge to the 802.16 network?
>
> 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 would like to understand the decision to use 4605 instead of 4541 which
> seems more suited to bridged environment.
>
> also applies to the enterprise deployment. In that environment, turning off
> broadcast may be inappropriate.
>
> 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.
>
> All permanently assigned addresses? Even all-routers, for instance? Be more
> specific.
>
> 6.4. Proxy ARP
>>
> hosts at the subscriber side, where does that leave hosts that are relying
> on RAs? (E.g., hosts complying with RFC 3775.)
>
> Again, given that this must work with regular Ethernet-attached hosts, to
> what extent are these statements useful?
>
> Also, this document should not make any recommendations on what particular
> address assignment mechanism should be employed (4862, 3041, etc).
>
> cause denia-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.
>
> 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?
>
> Editorial:
>
> 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.
>

-- 
Soohong Daniel Park [at] Samsung Electronics
Standard Architect, http://blog.naver.com/natpt
_______________________________________________
16NG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/16ng

---

From: "Riegel, Maximilian (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 1 Jul 2008 10:08:26 +0200

Thanks for the thorough review raising a couple of good questions. I
don't believe we need 4 weeks for the answers. A couple of the questions
may only require some explanation, while others need a little time to
reconsider the dependencies. Nevertheless I hope we are able to provide
the response in the next couple of days.
 
Bye
Max

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Daniel Park
Sent: Tuesday, July 01, 2008 5:11 AM
To: Jari Arkko
Cc: [email-masked];
[email-masked]
Subject: Re: [16NG] AD review of
draft-ietf-16ng-ip-over-ethernet-over-802.16

I am expecting authors will clean up all of your comments at upcoming
16ng F2F meeting. 1-hour is now reserved for our meeting, so I think 40
mins for EthernetCS and 20 mins for IPv4CS at this meeting. 

 

	Hi all,
	
	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.
	
	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 behaviour. 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. Why was RFC 4605 used instead of RFC 4541? What can
this spec mandate about the behaviour of hosts connected via a regular
Ethernet and a bridge to the 802.16 network?
	
	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.
	
	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.)

		  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/

		In the Public Access scenario, direct communication
between nodes is
		restricted because of security and accounting issues.

		6.1.1. <http://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.

		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.

		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.

		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.
	
	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.

		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.

		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.

		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?

		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.
<http://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.)

		9.2.2. <http://9.2.2./>  Address Configuration
		SS SHOULD derive its global IPv6 addresses based on
prefix and EUI-
		64-derived interface identifier

	Again, given that this must work with regular Ethernet-attached
hosts, to what extent are these statements useful?

		  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 denia-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.
	
	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?
	
	Editorial:

		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.

	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.

		This document does not introduce new vulnerability to
operations of

	any new vulnerabilities?
	
	the operations?

	
	Jari