Subject: [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt

From: <[email-masked]>
Date: Thu, 5 Feb 2009 15:08:59 +0100

FYI. A new ID has been submitted to IETF. This draft specifies new PPP IPCP options to be used in the context of Port Range solutions.

Comments are more than welcome.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 5 février 2009 15:00
À : [email-masked]
Objet : I-D Action:draft-boucadair-pppext-portrange-option-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Port Range Configuration Options for PPP IPCP
	Author(s)       : M. Boucadair, et al.
	Filename        : draft-boucadair-pppext-portrange-option-00.txt
	Pages           : 13
	Date            : 2009-02-05

This memo defines two IPCP (IP Configuration Protocol, [RFC1332]) Options to be used in the context of Port Range solutions.  IPCP is the configuration protocol used when PPP (Point-to-Point Protocol,
[RFC1548]) is deployed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boucadair-pppext-portrange-option-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Feb 2009 15:29:08 -0800

I like this draft overall, but I would restrict this so that only contiguous
port ranges are permitted.  Non-contiguous subnet masks are difficult for many
people to understand (even today) and I expect there would be similar
confusion with non-contiguous port ranges.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Thursday, February 05, 2009 6:09 AM
> To: [email-masked]; [email-masked]
> Subject: [BEHAVE] TR: 
> I-DAction:draft-boucadair-pppext-portrange-option-00.txt
> 
>  
> 
> FYI. A new ID has been submitted to IETF. This draft 
> specifies new PPP IPCP options to be used in the context of 
> Port Range solutions.
> 
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> [email-masked]
> This memo defines two IPCP (IP Configuration Protocol, 
> [RFC1332]) Options to be used in the context of Port Range 
> solutions.  IPCP is the configuration protocol used when PPP 
> (Point-to-Point Protocol,
> [RFC1548]) is deployed.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 5 Feb 2009 17:09:40 -0800

Yes.  :)

I had the same feedback last IETF.
This is the same thing all over again as a non-contiguous subnet mask,
which the industry effectively got rid of as having too many problems
in practice (but being fine in theory).

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Thursday, February 05, 2009 3:35 PM
To: Dan Wing
Cc: [email-masked]; [email-masked]
Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt

> confusion with non-contiguous port ranges.

do people have to understand these?

randy
_______________________________________________
shara mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/shara

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 07:35:18 +0100

Thank you for your comment.

There is a subtlety between subnet mask and port mask: subnets need to be hierarchical but not port ranges!

Non contiguous port range is proposed as a solution to assign with a single mask for instance "M" Port Ranges with "n" Port Ranges within the well-known Port Range. This means that well-known PR won't be assigned to the same user. 

I see other advantages on the usage of non contiguous PR: e.g. an attacker would have more difficulty to "guess" a port value within the Port Range.

By the way, I have the same question as Randy.

Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dave Thaler
Envoyé : vendredi 6 février 2009 02:10
À : Randy Bush; Dan Wing
Cc : [email-masked]; [email-masked]
Objet : Re: [BEHAVE] [shara]TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt

Yes.  :)

I had the same feedback last IETF.
This is the same thing all over again as a non-contiguous subnet mask, which the industry effectively got rid of as having too many problems in practice (but being fine in theory).

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Thursday, February 05, 2009 3:35 PM
To: Dan Wing
Cc: [email-masked]; [email-masked]
Subject: Re: [shara] [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt

> I like this draft overall, but I would restrict this so that only 
> contiguous port ranges are permitted.  Non-contiguous subnet masks are 
> difficult for many people to understand (even today) and I expect 
> there would be similar confusion with non-contiguous port ranges.

randy

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Feb 2009 22:47:24 -0800

> > subnets need to be hierarchical 
> 
> fwiw, paul francis publiched a scheme back in about '92 where
> subnet masks were not contiguous.  it was self-consistent.

Can you describe the adoption of the scheme in the last 16 years?

-d

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 07:50:39 +0100

By the way, the draft introduces the notion of non contiguous "Port Mask". Non-contiguous subnet masks are NOT mentioned in the draft.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 6 février 2009 00:29
À : BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]
Cc : [email-masked]
Objet : RE: [BEHAVE] TR: I-DAction:draft-boucadair-pppext-portrange-option-00.txt

I like this draft overall, but I would restrict this so that only contiguous port ranges are permitted.  Non-contiguous subnet masks are difficult for many people to understand (even today) and I expect there would be similar confusion with non-contiguous port ranges.

-d

> FYI. A new ID has been submitted to IETF. This draft specifies new PPP 
> IPCP options to be used in the context of Port Range solutions.
> 
> [email-masked] Envoyé : jeudi 5 février 2009 15:00 À : 
> [email-masked] Objet : I-D 
> Action:draft-boucadair-pppext-portrange-option-00.txt
> 
> [RFC1332]) Options to be used in the context of Port Range solutions.  
> IPCP is the configuration protocol used when PPP (Point-to-Point 
> Protocol,
> [RFC1548]) is deployed.
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Feb 2009 23:11:14 -0800

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Thursday, February 05, 2009 10:35 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [BEHAVE] [shara]TR: 
> There is a subtlety between subnet mask and port mask: 
> subnets need to be hierarchical but not port ranges!

I disagree.  Port ranges all belong to the same IP address -- 
from the view of the rest of the Internet.  This is akin to the 
rest of the Internet's view of a subnet.  It is only the local
IP address (subnet) that is aware of the separation of ports
(or IP addresses) to individual hosts.

> Non contiguous port range is proposed as a solution to assign 
> with a single mask for instance "M" Port Ranges with "n" Port 
> Ranges within the well-known Port Range. This means that 
> well-known PR won't be assigned to the same user. 
> 
> I see other advantages on the usage of non contiguous PR: 
> e.g. an attacker would have more difficulty to "guess" a port 
> value within the Port Range.

draft-boucadair-pppext-portrange-option does not describe
this advantage.  I am not convinced this would thwart an
attacker significantly.  If a user is permitted XXXX ports,
an attacker can determine what ports they are by a range
of contiguous bits or a range of non-contiguous bits.  I
agree the attacker has to perform more probes to learn
the non-contiguous bit pattern, of course.  But an analysis
of this advantage would be useful.

> By the way, I have the same question as Randy.

I am not talking about the proverbial Grandma or "Joe
Sixpack" when I say "users".  Those users have no
need to understand 255.255.255.0, or IP addresses,
or ARP.

However, network administrators are users, and they need 
to understand these bit-masks in order to successfully
configure equipment.  Based on industry experience with
IP, non-contiguous subnet masks are not used in very
many networks.  This is because the complexity to use
them exceeds their value.

Justification of the value of non-contiguous port masks 
would be useful.

-d

> Objet : Re: [BEHAVE] [shara]TR: 
> This is the same thing all over again as a non-contiguous 
> subnet mask, which the industry effectively got rid of as 
> having too many problems in practice (but being fine in theory).
> 
> -Dave
> 
> Subject: Re: [shara] [BEHAVE] TR:

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 08:31:48 +0100

Dan,

We have a draft pending on Internet-Draft submission tool: http://www.ietf.org/proceedings/staging/draft-bajko-pripaddrassign-00.txt that describes what you ask. (Note: that link will not work after the draft gets published).

Please check that out, it is discussing more about this and also describing alternative solution using cryptographically random port allocation scheme.

These administrators could configure a host to get say 1000 ports, but of course not specific ones as those would be randomized from the 64K-1K range. With proper tools administrators can of course see what ports are/were assigned to users.

Best regards,

        Teemu

>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of ext Dan Wing
>Sent: 06 February, 2009 09:11
>To: [email-masked];
>[email-masked]; [email-masked]
>Subject: Re: [BEHAVE] [shara]TR:
>from the view of the rest of the Internet.  This is akin to
>the rest of the Internet's view of a subnet.  It is only the
>local IP address (subnet) that is aware of the separation of
>ports (or IP addresses) to individual hosts.
>
>> Non contiguous port range is proposed as a solution to assign with a
>> single mask for instance "M" Port Ranges with "n" Port Ranges within
>> the well-known Port Range. This means that well-known PR won't be
>> assigned to the same user.
>>
>> e.g. an attacker would have more difficulty to "guess" a port value
>> within the Port Range.
>
>draft-boucadair-pppext-portrange-option does not describe this
>advantage.  I am not convinced this would thwart an attacker
>significantly.  If a user is permitted XXXX ports, an attacker
>can determine what ports they are by a range of contiguous
>bits or a range of non-contiguous bits.  I agree the attacker
>has to perform more probes to learn the non-contiguous bit
>pattern, of course.  But an analysis of this advantage would be useful.
>
>I am not talking about the proverbial Grandma or "Joe Sixpack"
>when I say "users".  Those users have no need to understand
>255.255.255.0, or IP addresses, or ARP.
>
>However, network administrators are users, and they need to
>understand these bit-masks in order to successfully configure
>equipment.  Based on industry experience with IP,
>non-contiguous subnet masks are not used in very many
>networks.  This is because the complexity to use them exceeds
>their value.
>
>Justification of the value of non-contiguous port masks would
>be useful.
>
>-d
>
>
>>
>>
>> Med
>>
>>
>>
>> De : [email-masked] [mailto:[email-masked]] De la
>> part de Dave Thaler Envoyé : vendredi 6 février 2009 02:10 À : Randy
>> Bush; Dan Wing Cc : [email-masked]; [email-masked] Objet : Re:
>> [BEHAVE] [shara]TR:
>subnet mask,
>> From: [email-masked] [mailto:[email-masked]]
>On Behalf
>> Of Randy Bush

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 08:55:06 +0100

Hi all,

Forbid people to use non-contiguous port ranges, at this point in time, seems rather dangerous to me.

What if it later appears that for some use cases it is an interesting feature? As Med and Teemu pointed out it could improve, to some extent the security. 
If we say we do not permit non contiguous port ranges, does that mean implementers will have to code it? (as nowadays it is impossible to use 240/4).

May be we could simply say that if there is no particular reason to do otherwise, by default use contiguous port ranges

Regards,

Pierre

> De : [email-masked] [mailto:[email-masked]] 
> De la part de Dan Wing
> Envoyé : vendredi 6 février 2009 08:11
> À : BOUCADAIR Mohamed RD-CORE-CAE; 
> Objet : Re: [shara] [BEHAVE]TR: 
> > On Behalf Of Randy Bush

---

From: Rémi Després <[email-masked]>
Date: Fri, 06 Feb 2009 10:40:22 +0100

Mohamed,

Thanks for this draft.

It does contribute to the promotion of Port-Extended
IPv4 addressing, which is the only known way to AVOID, during the IPv4-IPv6 coexistence period, that users
MUST
depend on CGNs .

Yet, the mask and value parameters which you propose, to express port
ranges, are in my understanding, both too complex and too limited.

- too complex, because it's hard to imagine a practical use of non
contiguous port ranges. (In particular I don't see where to use the
chosen example
of ports xxx0x1xxxxxxxxxx.)

- too limited, because it cannot express an IPv4-address extension
based on dynamic ports, which, as I already discussed in various
places, is IMO the most simple choice for a realistic deployment.

For
example, no mask and value parameters can express 4-bits address extension based on dynamic ports (i.e.
with ports 11EEEExxxxxxxxxx, where Es are the address extension bits).

If no need is identified for more complex solutions than dynamic-ports
only, I then propose to amend the document so that parameters are
simplified, e.g. but not necessarily to become:

Port Prefix Length (6 in the above example).

Port Prefix Value (11EEEE0000000000 in the above example).

Some other set of parameters could be
proposed if  a good reason would be found
to also use Well-Known ports and/or Registered ports. (I don't see such
a reason, while avoiding interference with firewalls is an important
reason  against),

Cheers,

RD

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 11:27:53 +0100

Dear Rémi,
 
Thank your for your comments.
 
Please see inline.
 
Cheers
Med

  _____  

De : Rémi Després [mailto:[email-masked]] 
Envoyé : vendredi 6 février 2009 10:40
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : [email-masked]; [email-masked]
Objet : Re: [BEHAVE] TR: I-D Action:draft-boucadair-pppext-portrange-option-00.txt

Mohamed,

Thanks for this draft.
It does contribute to the promotion of Port-Extended IPv4 addressing, which is the only known way to AVOID, during the IPv4-IPv6 coexistence period, that users MUST depend on CGNs . 

Yet, the mask and value parameters which you propose, to express port ranges, are in my understanding, both too complex and too limited. 
- too complex, because it's hard to imagine a practical use of non contiguous port ranges. (In particular I don't see where to use the chosen example of ports xxx0x1xxxxxxxxxx.) 
[Med] Non contiguous port ranges are only on example. The specification supports both. There is no overhead of the spec which is due to the type of the assigned port ranges 
- too limited, because it cannot express an IPv4-address extension based on dynamic ports, which, as I already discussed in various places, is IMO the most simple choice for a realistic deployment.
[Med] Contiguous port ranges could be used for this purpose.  

For example, no mask and value parameters can express 4-bits address extension based on dynamic ports (i.e. with ports 11EEEExxxxxxxxxx, where Es are the address extension bits). 

If no need is identified for more complex solutions than dynamic-ports only, I then propose to amend the document so that parameters are simplified, e.g. but not necessarily to become:
   Port Prefix Length (6 in the above example).
   Port Prefix Value (11EEEE0000000000 in the above example).
[Med] I need to think about that a little bit more. 

Some other set of parameters could be proposed if  a good reason would be found to also use Well-Known ports and/or Registered ports. (I don't see such a reason, while avoiding interference with firewalls is an important reason  against), 
[Med] I think assigning the overall well known port range to a single user is not **fair**, IMO means to distributed these values should be encouraged. And again, this is naturally supported by our proposal. The values to be carried in an IPCP conf message is out of scope. SP are free to assign the Port Masks they want!

Cheers,

RD

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 12:58:05 +0100

> (or IP addresses) to individual hosts.

I see your point. What we had in mind is different; when we say subnets
are hierarchical we mean a subnet can be in a bigger subnet which can be
in a bigger subnet, and so forth (within the limit of the 32 bits!).
There are some cases where this scheme can apply to port ranges, when
several A+P devices are cascaded, as a CPE and its hosts. But in a
configuration where only CPEs are Port Range-enabled there is no
hierarchy from this standpoint.

Another difference with subnets is if subnet bits are not contiguous,
the bits in between do exist in the address, are completely part of the
address, and refer, as a whole, to the host id. If Port Range bits are
not contiguous, there are no other significant bits melt with that have
a separate meaning.

What I'm trying to say is, it is not because non contiguous bits are a
bad thing for subnets that they are automatically bad for Port Ranges.

Regards,

Pierre

---

From: <[email-masked]>
Date: Fri, 6 Feb 2009 08:37:23 +0100

Dan,

The attached document should appear shortly in the ietf directories. Section 2 tries to justify the need for non-contiguous port range allocation. Sections 4 and 5 explain how the non-contiguous port range and random port delegation works.

- gabor

  >From: [email-masked] [mailto:[email-masked]] On Behalf Of
  >ext Dan Wing
  >Sent: Thursday, February 05, 2009 11:11 PM
  >To: [email-masked]; [email-masked];
  >[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Feb 2009 08:35:04 +0900

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Feb 2009 13:55:07 +0800

> Yes.  :)

they do?  when?

> do people have to understand these?

imiho, this is like ASDOT notation.  useless.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Feb 2009 14:40:33 +0800

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Feb 2009 14:58:47 +0800

> Can you describe the adoption of the scheme in the last 16 years?

no need to.  the point is that they need not be.  you are not
required to like it.

randy