Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP)
draft-boucadair-pppext-portrange-option-09

[Ballot comment]
In section 2.2.1 there is confusion about randomization.  The ports are selected psuedo-randomly, definitely not randomly.

The document does not mention whether the ports either being delegated or forwarded belong to particular transport protocols or all transport protocols.  The authors proposed to add text saying that this applies to all transport protocols, but it should probably list them specifically by name to be clear.

The document does not mention any changes or limitations to how applications and an OS kernel would actually interact after either being delegated ports, or having them setup for forwarding.  Adding clear reference to where the usage of these ports is discussed in A+P would be useful, I think.

The document does not mention how ports would be revoked or reaped after use.  The authors proposed that reaping can only occur when the link is terminated.  That may be limiting operationally, and the limitation should be understood and discussed, I believe.

[Ballot comment]
#1) This probably shows my complete lack of understanding, but I just wanted to check.

draft-ietf-tsvwg-iana-ports-10 says:

  o  the Dynamic Ports, also known as the Private or Ephemeral Ports,
      from 49152-65535 (never assigned)

and RFC 6056 says:

  o  The Dynamic and/or Private Ports, 49152 through 65535

  The dynamic port range defined by IANA consists of the 49152-65535
  range, and is meant for the selection of ephemeral ports.

If draft-boucadair-pppext-portrange-option provides another option for picking a port in the range supported by RFC 6056 why does it address ports in the range 1024-65535 and not 49152-65535?

#2) The draft makes the following claim:

  For improved security an option for delegating cryptographically
  random port range is defined.

Improved over what?  Nothing, the algorithms presented in RFC 6056, or something else?

#3) This didn't make sense to me:

  Other port generator functions may be predefined in Standards Track
  documents and allocated a not yet allocated 'function' value within
  the corresponding sub-option type field.

I think you're saying that there's an option to specify another cryptographic algorithm in "function" element (e.g., "2")?  I'm curious why you'd need to define them in a Standards Track document.  Would that document be updating some internal Huawei registry?  Based on the empty IANA considerations, I assume it's not going to be hosted at IANA.

[Ballot comment]
Seeing no RFC 5742 issues here, I am balloting "No Objection".

However, please specify the byte order of the binary fields. Although network byte order (the most significant byte first) is almost universally used, there are some exceptions, so it is important to spell this out.

[Ballot discuss]
This Discuss is intended to be resolved in discussion with the IESG on or before 25th August.

No author-action is requested.

I agree with Jari's recommendation wrt his RFC 5742 review subject to understanding whether the PPPext working group might consider working on a standards track function to achieve the same result. If that were the case, then the existence of a non-standard, vendor-specific solution published as an RFC might be a distraction.

[Ballot comment]
I'd share in some of the comments as to the maturity level of
this spec. But that's an ISE issue I guess.

I also don't get why it says that other functions may be
"predefined (sic) in *Standards Track* documents" when
its an independent submission and nothing to do with
the standards track.

[Ballot discuss]
The document does not mention whether the ports either being delegated or forwarded belong to particular transport protocols or all transport protocols.

The document does not mention any changes or limitations to how applications and an OS kernel would actually interact after either being delegated ports, or having them setup for forwarding.

The document does not mention how ports would be revoked or reaped after use.

I have been assigned the task of reviewing draft-boucadair-pppext-portrange-option. This draft has been submitted to be published via the RFC Editor as an independent submission. While these drafts are published independently from the IETF, the RFC Editor asks the IESG to check the drafts for collision with IETF work and adherence with IANA rules. My task was to perform such a review for the draft, in preparation of the full IESG's review of the document next week. This is not a technical review, the IESG nor the IETF makes no statement about the contents of the draft. However, in some cases I provide some technical comments on an as-is basis.

My recommendation for the IESG is the following:

  1. The IESG has concluded that there is no conflict between this
      document and IETF work.

What follows is a strictly personal review comments that may be useful for the RFC Editor and the authors. Overall, the draft is interesting technical work and suitable for publication as an independent submission. However, unless I'm missing something it seems to have a technical issue in the definition of what format is actually used. Secondly, it has in my opinion a serious reference problem, as parts of what would be important for implementors to understand exist in an Internet Draft that is not in the RFC Editor or IETF process at this time.

> The Port Range IPCP option adheres to the format defined in Section
> 1.1 of [RFC2153].  The "value" field of the option defined in
> [RFC2153] when conveying Port Range IPCP Option is provided in
> Figure 1.

>      |              (1) IPCP Configure-Request        |
>      |                IP ADDRESS=0.0.0.0              |
>      |                PORT RANGE VALUE=0              |
>      |                PORT RANGE MASK=0              |
>      |===============================================>|
>      |                                                |
>      |              (2) IPCP Configure-Nak            |
>      |                IP ADDRESS=a.b.c.d              |
>      |                PORT RANGE VALUE=80            |
>      |                PORT RANGE MASK=496            |
>      |<===============================================|

Unless I'm missing something obvious, there seems to be some confusion here. Section 1.1 of RFC 2153 is the vendor specific packet format. Section 2.1 is the LCP option format. I think you meant the latter. If not, much of the remainder of the draft needs a rewrite, as packets would exist at the same level as the Configure-Request and Configure-Nak packets.

> o  M: mode bit.  It indicates the mode the port range is allocated
>    for.  A value of zero indicates the port ranges are delegated,
>    while a value of 1 indicates the port ranges are port forwarded.

The difference between delegation and forwarding is unclear to me. What different behaviour is called for by the client depending on the different values of M?

> The benefits of the approach and the method to calculate the
> delegated ports set are described in [I-D.bajko-pripaddrassign].
> o  Function: A 16 bit field whose value is associated with predefined
>    encryption functions.  This specification associates value 1 with
>    the predefined function described in Section 5 of
>    [I-D.bajko-pripaddrassign].
> 7.2. Informative References
>
>  [I-D.bajko-pripaddrassign]
>            Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
>            "Port Restricted IP Address Assignment",
>            draft-bajko-pripaddrassign-03 (work in progress),
>            September 2010.


Draft-bajko-pripaddressing is not in RFC Editor queue or in IETF process, at least according to the datatracker. It is very clearly a normative reference, and I would personally not recommend the RFC Editor to publish incomplete specifications without all normative references being also RFCs.

The draft draft-boucadair-pppext-portrange-option-06
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

This draft was submitted in September 2010, and was
reviewed by Mark Townsley and Bruce Davie. After the
author had addressed the issues raised by the reviewers

I checked with James Carlson, former chair of the
pppext WG - his comment was that it had been discussed
briefly on the pppext list, but since it only requests
a vendor-specific pppext option under RFC 2153, he felt
that pppext had no particular view of it.

James also pointed out that there's an IPR declaration
that covers it. The authors have added a comment to
point that out.

Overall, I see this simply as a vendor describing their
implementation of th a ppp extension.

Thanks, Nevil (ISE)