Subject: [Softwires] Port Set Definition Algorithms Analysis

From: Tina TSOU <[email-masked]>
Date: Fri, 02 Mar 2012 15:35:37 +0000

Dear all,
You may be interested to comment on
http://datatracker.ietf.org/doc/draft-tsou-softwire-port-set-algorithms-analysis/

Abstract:
  This memo analyses some port set definition algorithms which
  encode port set information into IPv6 address so as to support
  stateless IPv4 to IPv6 transition technologies, e.g. 4rd-U and MAP.

Tetsuya, Simon and Tina

---

From: GangChen <[email-masked]>
Date: Tue, 6 Mar 2012 18:24:34 +0800

Hello Tina,

Could you help to clarify the sentence:

   *1 MAP and divi-pd provide better security than 4rd-U, because they
   provide more variation in port set definition.

I guess they should have similar features on security

Gang

2012/3/2, Tina TSOU <[email-masked]>:
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 6 Mar 2012 19:03:31 +0100

Hi Tina,

In this analysis, the 4rd-u port-set algorithm is presented as an instance of GMA algorithm (i.e. Generalized Modulus Algorithm).

I think it would be more appropriate to have it in its own category, e.g. that of "parameter-less" algorithms (it has no reference to any modulo operator, and isn't intended to generalize anything)
It happens to to be alone in this parameter-less category but, since the goal is standardization, isn't this more good than evil? 

If you would have plan for a new version, this could maybe be taken care of.
Otherwise, this can be taken as just a comment inspired by your interesting document.

Thanks,
RD

---

From: Tina TSOU <[email-masked]>
Date: Tue, 06 Mar 2012 18:24:06 +0000

Sent from my iPad

> I guess they should have similar features on security
Agreed. No much difference between MAP, divi-pd, and 4rd-U with regard to security. So I propose to remove this sentence.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 06 Mar 2012 13:28:56 -0500

> It happens to to be alone in this parameter-less category but, since the goal is standardization, isn't this more good than evil?

I'm not sure moving 4rd-U to its own section would be useful for the 
purposes of the document. What's important here is the similarity 
between 4rd-U, MAP, and divi-pd, not the number of parameters that they 
use. This similarity allows us to derive a single summary table 
containing properties shared by all of them (section 3.1.4).

Note that the draft says "GMA-style" algorithms, which gives us some 
leeway...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Maoke <[email-masked]>
Date: Wed, 7 Mar 2012 17:58:17 +0900

2012/3/7 Tina TSOU <[email-masked]>

> Agreed. No much difference between MAP, divi-pd, and 4rd-U with regard to
> security. So I propose to remove this sentence.
>

well, *better security* might be an inaccurate expresssion. i suppose MAP
provides better flexibility than 4rd-U. personally, i understand the reason
of 4rd-U requiring fixed offset (4bits) is to support the longest-match of
port for CE-finding in the mesh mode (i.e., the MAX PSID). it is a
tradeoff. without the fixed offset, longest-match fails for the PSID
matching and there must be a way of distributing CE's PSID to other CEs.
however, it does also confuses me that the newest 4rd-U draft doesn't
mention the MAX PSID feature (or maybe i missed something).

---

From: Rémi Després <[email-masked]>
Date: Wed, 7 Mar 2012 11:03:04 +0100

Le 2012-03-06 à 19:28, Simon Perreault a écrit :

> I'm not sure moving 4rd-U to its own section would be useful for the purposes of the document. What's important here is the similarity between 4rd-U, MAP, and divi-pd, not the number of parameters that they use. This similarity allows us to derive a single summary table containing properties shared by all of them (section 3.1.4).

No problem

> Note that the draft says "GMA-style" algorithms, which gives us some leeway...

Well, no big concern.
Just making the point that there is no need to understand GMA to understand 4rd-u.

Thanks,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 7 Mar 2012 11:24:11 +0100

Hi Tina,

> Agreed. No much difference between MAP, divi-pd, and 4rd-U with regard to security. So I propose to remove this sentence.

+1 (see below)

> 
> well, *better security* might be an inaccurate expresssion. i suppose MAP provides better flexibility than 4rd-U. personally, i understand the reason of 4rd-U requiring fixed offset (4bits) is to support the longest-match of port for CE-finding in the mesh mode (i.e., the MAX PSID). it is a tradeoff. without the fixed offset, longest-match fails for the PSID matching and there must be a way of distributing CE's PSID to other CEs. however,

> it does also confuses me that the newest 4rd-U draft doesn't mention the MAX PSID feature (or maybe i missed something).

The max PSID feature, present in 4rd-u-00 and -01 (i.e. before IETF 82), was abandoned during the Taipei meeting (November 2011)
It no longer appeared in -02 (December 29).

Reasons of the 4rd-u fixed offset are (ref. sec 4.3 of -04):
"NOTE: The choice of the PSID position in Port fields has been guided by the following objectives: (1) for fairness, avoid having any of the well-known ports 0-1023 in the port set specified by any PSID value (these ports have more value than others); (2) for compatibility RTP/RTCP [RFC4961], include in each port set pairs of consecutive ports; (3) in order to facilitate operation and training, have the PSID at a fixed position in port fields; (4) in order to facilitate documentation in hexadecimal notation, and to facilitate operation and training, have the PSID at a fixed position in port fields; (4) in order to facilitate documentation in hexadecimal notation, and to facilitate operation and training, have the PSID at a fixed position in port fields; (4) in order to facilitate documentation in hexadecimal notation, and to facilitate."

Hope it clarifies.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Thu, 8 Mar 2012 19:01:20 +0900

2012/3/7 Rémi Després <[email-masked]>

> however,
> it does also confuses me that the newest 4rd-U draft doesn't mention the
> MAX PSID feature (or maybe i missed something).
>
>
> The max PSID feature, present in 4rd-u-00 and -01 (i.e. before IETF 82),
> was abandoned during the Taipei meeting (November 2011)
> "NOTE: The choice of the PSID position in Port fields has been guided by
> the following objectives: (1) for fairness, avoid having any of the
> well-known ports 0-1023 in the port set specified by any PSID value (these
> ports have more value than others); (2) for compatibility RTP/RTCP
> [RFC4961], include in each port set pairs of consecutive ports; (3) in
> order to facilitate operation and training, have the PSID at a
> fixed position in port fields; (4) in order to facilitate documentation in
> hexadecimal notation, and to facilitate operation and training, have the
> PSID at a fixed position in port fields."
>
>

Remi,

point (1) is qualified for the individual use case but not available for
the enterprise environment, where surely it is possible that one put all
well know services under a same CE. but if MAP or 4rd-U states enterprise
use case is NOT to be supported, it is fine. point (2) is qualified but not
a sufficient condition to derive the fixed position of PSID. point (3) and
(4) is about the human reading on the PSID. however, the MAP or 4rd-U
address has been human-unfriendly. i don't see training and operation on
easy-to-read PSID is significant.

therefore i think MAXPSID, though it is abandoned, is a convincing reason
of having fixed position of PSID.

- maoke

---

From: Rémi Després <[email-masked]>
Date: Thu, 8 Mar 2012 16:43:14 +0100

Maoke,
Thanks for the discussion (valuable a usual).
More below.

Le 2012-03-08 à 11:01, Maoke a écrit :

> "NOTE: The choice of the PSID position in Port fields has been guided by the following objectives: (1) for fairness, avoid having any of the well-known ports 0-1023 in the port set specified by any PSID value (these ports have more value than others); (2) for compatibility RTP/RTCP [RFC4961], include in each port set pairs of consecutive ports; (3) in order to facilitate operation and training, have the PSID at a fixed position in port fields; (4) in order to facilitate documentation in hexadecimal notation, and to facilitate operation and training, have the PSID at a fixed position in port fields."
>  
>  
> Remi,
>  
> point (1) is qualified for the individual use case but not available for the enterprise environment, where surely it is possible that one put all well know services under a same CE.

> but if MAP or 4rd-U states enterprise use case is NOT to be supported, it is fine.

Actually, enterprise are in scope (last sentence of the ISP definition).
The point that enterprise environments may have specific use cases is therefore valuable.

To keep nibble alignment, and avoid unnecessary flexibility, while permitting some assignment(s) of ports 0-1023, would a rule parameter with the following two values cover your point? 
- Full fairness  (=> offset = 4)
- WKPs assignable to one CE per address (=> offset = 0)

> point (2) is qualified but not a sufficient condition to derive the fixed position of PSID. point (3) and (4) is about the human reading on the PSID. however, the MAP or 4rd-U address has been human-unfriendly. i don't see training and operation on easy-to-read PSID is significant.
>  
> therefore i think MAXPSID, though it is abandoned, is a convincing reason of having fixed position of PSID.

While I understand the previous point, I don't get this one:  MaxPsid could AFAIK work as well with rule-dependent offsets.
This comment is just in view of keeping common understanding of issues but, since MaxPsid is now out of scope, I will have no problem if we leave the subject for the time being.

RD