[dhcwg] Comments on draft-bajko-pripaddrassign-04 and draft-wu-dhc-port-set-option-00

[Tomek Mrugalski <[e-mail]>]

Dear group, dear authors,

Those 2 drafts are discussing similar approaches. As both are presented
by the same person, I suppose there is a likelihood of merge between
them. Therefore I'd like to comment on both of them in a single mail.

I do not have experience with port-restricted addresses, so please
forgive me if some comments are not valid.

Sorry for sending those comments so shortly before the meeting.

Comments common for both drafts:

1. Well known port assignment problem
Here's the generic issue with both proposals. I seems generic to any A+P
proposals and the whole class of fixed port protocols, so it is much
wider than just "those two drafs and DHCP" problem.

Let's assume a simple case of 2 hosts sharing a single IPv4 address. One
of them gets 68 port. What would the other host use as source port of
its DHCP transmissions? How is server/relay supposed to send back
responses to that client?

Here's a relevant sentence from RFC2131, section 4.1:
"DHCP messages from a server to a client are sent to the 'DHCP client'
port (68).". Sure, you can update this to say that a client may use any
port and server is supposed to respond to client's source port. That
will work for clients directly connected to server. But it will break
down when relays are in use. Relay will be able to pass Discover message
to the server, the server will be able to pass back the response to the
relay, but then relay will not know the client's source port, because
relays are stateless and they don't keep information about previously
relayed messages.

That problem remains to be solved. When proposing a solution, make sure
you don't propose that the relay keeps the state. Relay are should
remain stateless. Some form along the lines of "relay inserts RAI option
that specifies original client's port number and server echoes it back"
will probably do the trick. See draft-ietf-dhc-dhcpv4-over-ipv6-02 for
an example of similar approach with an IPv6 address.

2. Port allocation options
There are many proposals regarding port set allocation options and
possibly more may appear. For that purpose, it would be better to define
a single container option that contains sub-options with a particular
option assignment type (continuous range, non-continus, GMA etc). That
approach is used in proposed OPTION-IPv4-PRA option in draft-bajko.

It would also simplify interactions. If those options were implemented
as separate options, client would be supposed to request all of them and
server will respond with those that are reflecting port allocation
policy chosen by a network administrator. It doesn't make sense to mix
different port-sets in a single deployment IMHO. This would also brings
in unfortunate failure modes. What is the server supposed to do, if it
is configured to support continuous port-sets, but client requests only
non-continuous? I think the better solution would be for a client to
simply request IPv4-PRA option, and then deal with whatever sub-options
it gets back from the server.

3. Backward compatibility
I like the idea of setting yiaddr to 0.0.0.0 mentioned in draft-bajko.
Draft-wu does not not have this behavior. If the client does not
understand received port set options, it will simply use the whole port
range for a given address. Other A+P clients will suffer.

4. ARP and DHCPDECLINE
Excuse my ignorance in regards of A+P solutions, but how is ARP supposed
to work in that environment? Obviously DHCPDECLINE must not be used and
the whole duplicate address detection system must be disable somehow.
There should be a section added that discusses that.


Comments for draft-wu-dhc-port-set-option:

The assumption here is that the ports discussed are TCP and UDP ports,
right?. That should be explicitely mentioned.

Do clients must support both options or are they allowed to support only
one?

Section 3.1:
Is allocating port 0 allowed?

Section 3.2: I-D.mdt-softwire-mapping-address-and-port is now
I-D.ietf-softwire-map.

Section 7: Security considerations
You should discuss allocation stategies somewhere and their impact on
allocation. In particular, what should server when handling mix of
client do and don't support port-restricted IPs. It doesn't have to be
in security considerations section. Perhaps a separate section will be
better. But security consideration section must mention that client
failing to process received port-set will cause problems.

In DHCP, client typically ingores the options that it does not
understand or considers for some reason invalid and continues message
processing for other options. That is not the case here. If for any
reason, the client is not able to use port-set options, it must not
continue as conflict with other hosts that share the address will ensue.

You should discuss attacks that rely on guessing port numbers here. With
the smaller port-range available, guessing becomes easier. Sniffing the
DHCP communication will make that attack easier.

References:
Please remove reference RFC3527, it is not used.


Comments for draft-bajko-pripaddrassign-04:

Section 1: Introduction
> using a newly defined IPv4 DHCP [RFC2131] option
Depending on how you read that sentence, someone may think that DHCPv4
is now. Don't call DHCPv4 a newly defined (unless you're a geologist).
A simple rewording will do the trick here.

Section 3.
Suboptions list mentions 3 options, yet only 2 are defined.

First sentence on page 6 mentions sub-option type 4 that is not defined.

In general, it would be easier to understand, if the IPv4-PRA option
description contained just the "sub-options" field and all suboptions
started with sub-opt code and length fields.

Suboption lengths mentioned in section 3 should be moved to the
appropriate subsections that describe particular sub-options.

Section 3.1
Since both suboptions (1 and 2) contain IPv4 address, it makes sense to
move that field to the parent IPv4-PRA option.

Section 6.1
I like the trick with setting yiaddr to 0.0.0.0. It's a clever way to
eliminate clients that do not support this extension.

This section allows for a client to start another DHCPDISCOVER if it
needs additional ports. How is it going to be renewed? Is client
expected to maintain 2 separate state machines and send separate
REQUEST/Renewing messages? How is it going to be released? Two separate
RELEASE messages?

What is client supposed to do, if server sends more than one port-set
sub-options?

Nitpick:
How did you generate that draft? Athough its header on the first page
shows valid dates, the footer on each page says: "Expires March 27,
2011" and the header shows the date as September 2010.

Hope that helps,
Tomek