Subject: Re: [Softwires] Demo of draft-penno-softwire-sdnat-02 -- Sunday 25th from 15h30 to 17h00 room #201 at IETF in Paris

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Mar 2012 08:42:02 +0200

The principle is good, details are not:
 - only switched (giga) Ethernets were used (no wireless)
 - the PCP should get double arrow
 - all SD-B4s run a PCP/NAT-PMP/UPnP-GID-v1+v2 server
  (in fact they have the same kind of softwares, the laptop just offers
   more tools, 10000 times larger stable storage, a screen where wireshark
   can show packets, etc)
 - the port range (never a set for the SD-CPE) was configured by
  DHCPv4 over IPv6 too (ideally, we had time only for the static setup)

Thanks

[email-masked]

PS: we have a picture too but I prefer to finish the demo setup than
to fix the picture (same effort, better result :-).

---

From: Qi Sun <[email-masked]>
Date: Tue, 27 Mar 2012 13:16:49 +0800

Hi Francis,

      Thank you for your correction~
       Here are some questions about the demo and SD-NAT.

      1. As I see, the bindings of v6 and v4+ports are deterministic and
pre-configured on the AFTR. Will it be of great cost if they are installed
using NETCONF which is mentioned in one of Alain's emails?
      2.About the DHCPv4 over IPv6 server, how do you deal with the Server
ID option issue?
      3.Does SD-NAT mechanism support the allocation of non-continuous port
set (e.g. using GMA stated in MAP draft)?

      Thank you again!

Qi Sun

PS: If possible, will you post your picture? That would be great for me~

2012/3/26 Francis Dupont <[email-masked]>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2012 09:47:21 +0200

>  using NETCONF which is mentioned in one of Alain's emails?

=> it seems the question is about the ISC AFTR and not AFTR in general:
the ISC AFTR uses a configuration file (ASCII text), you can change it
and push it to the running daemon using a (smooth) reload or a (hard)
reboot command (there is no dynamic NAT entries to lose so it doesn't
matter :-). Now the provisioning system can use what it wants, we even
provide some XML tools to manage and push the config... BTW for the
demo I wrote some python scripts and use the built-in A+P/PRR support
(I am more concerned about this as the full NAT code is more than
over engineered for its use in a SD-AFTR :-).

>        2.About the DHCPv4 over IPv6 server, how do you deal with the Server

=> I didn't configure the server to send one (it is possible but I believe
it is not in the spirit of the I-D). Fortunately the ISC DHCPv4 client
doesn't require a server ID option so it works without hacks. Note
this behavior is compliant but the opposite one (require a server ID
option and drop all DHCPOFFER without one) is compliant too.

>  set (e.g. using GMA stated in MAP draft)?

=> SD-NAT is ambiguous:
 - I think the SD-CPE / SD-B4 should only support a range (i.e.,
  continuous set) because as far as I know it is already supported
  by all SD-CPEs without changing a line of code (i.e., to transform
  a CPE / B4 into a SD-CPE / SD-B4 you need to change some (one for a
  CPE using Linux) lines in the config. So even there are any reasons
  this point is critical for the deployment.
 - the SD-CGN / SD-AFTR is different. I believe it should propose a GMA
  stateless/deterministic/algorithmic translation. So I wrote to a python
  script generating an ISC AFTR config with static NAT entries but for
  the demo I started with no translation aka A+P aka PRR config because
  it was simpler, suitable for a demo, etc, and I had the good surprise
  to discover it is compatible too with the new version of the SD-NAT
  document (even I disagree about this change :-).

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 27 Mar 2012 02:25:40 -0700

What was the use case for non-contigous port sets?

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2012 13:02:15 +0200

>  What was the use case for non-contigous port sets?

=> cf draft-tsou-softwire-port-set-algorithms-analysis-01.txt

   A good port set definition algorithm must be reversible, easy to
   implement, and should be able to define non-continuous or random port
   sets for better security, be able to exclude the well known ports, 0
   ~ 1023 or 0 ~ 4095, etc.

obviously pure port range aka contigous port set is not "good".

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 27 Mar 2012 04:10:06 -0700

On 3/27/12 4:02 AM, "Francis Dupont" <[email-masked]> wrote:

>   implement, 

A contiguous, direct mapping is the easiest to implement.

>and should be able to define non-continuous or random port
>   sets for better security,

If the ports are random at every new allocation then you need to store
state, right? Or do you mean they are randomize at initiation, what I
would call 'port shuffle'.

>be able to exclude the well known ports, 0
>   ~ 1023 or 0 ~ 4095, etc.

I can understand excluding 0-1024 ports.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2012 13:45:12 +0200

>  A contiguous, direct mapping is the easiest to implement.

=> I can't say no as I use it for the DS-Lite SD-NAT demo for
exactly this reason.

>  would call 'port shuffle'.

=> the second (the SD-CGN uses an algorithm which can be slightly more
complex than the identity :-).

Regards

PS: BTW if you want to discuss Tsou's I-D IMHO you should change the subject.

---

From: Qi Sun <[email-masked]>
Date: Tue, 27 Mar 2012 20:11:55 +0800

Hi Francis,

     A quick question: why is there a SD-CGN? Do you mean the second NAT at
AFTR used to reshape the out-of-range source port into the restricted port
range?
      If so, IMHO it is stateful, not using an algorithm. And I think it
still doesn't solve the security issue.

      Please correct me if there is any mistake~

     Thank you

Qi Sun

2012/3/27 Francis Dupont <[email-masked]>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 27 Mar 2012 14:33:00 +0200

>  AFTR used to reshape the out-of-range source port into the restricted port

=> there must be a SD-CGN which:
 - filter from SD-CPE to the Internet packets checking the SD-CPE uses
  the right IP address and ports in its assigned port range
 - route on address + port packets from the Internet to the right SD-CPE
optionally it can "suffle" the port bits but there is no agreement
about this (so it is *optionally*).

>  still doesn't solve the security issue.

=> no, the second NAT is no way stateful. Only the SD-CPE is stateful
(and port range restricted).

Regards