[Softwires] AD review of draft-ietf-softwire-dual-stack-lite (final part 3)

[Jari Arkko]

I have now completed my review of the draft. Here are the remaining comments: Overall: The draft is in relatively good shape. I saw a number of cases where you should have been more precise in the specification, but those cases can definitely be corrected. There are a few missing things, but again something that can be taken care of. I am expecting a new revision. Technical: Shouldn't the draft talk about how a service provider AFTR makes it less likely that the user can exert control with protocols like UPnP-IGD? You should bring up this issue up early in the document, and then you can point to Appendix C for possible future work around that limitation. What happens if two B4s are chained together, both using the reserved address range? However, moving the NAT functionality from the home gateway to the core of the service provider network and sharing IPv4 addresses among customers create additional requirements when logging data for abuse usage. With any architecture where an IPv4 address does not uniquely represent an end host, IPv4 addresses and a timestamps are no longer sufficient to identify a particular broadband customer. Additional information such as transport protocol information will be required for that purpose. For example, we suggest to log the transport port number for TCP and UDP connections. What needs to be logged depends on the element that you are in. A peer would log the other side's transport port number, an AFTR would log the line/tunnel ID and the transport port number. The AFTR performs translation functions for interior IPv4 hosts at RFC 1918 addresses or at the IANA reserved address range (TBA by IANA). How do we know which address range is being used? If the interior host is properly using the authorized IPv4 address with the authorized transport protocol port range such as A+P semantic for the tunnel, the AFTR can simply forward without translation to permit the authorized address and port range to function properly.  All packets with unauthorized interior IPv4 addresses or with authorized interior IPv4 address but unauthorized port range MUST NOT be forwarded by the AFTR.  This prevents rogue devices from launching denial of service attacks using unauthorized public IPv4 addresses in the IPv4 source header field or unauthorized transport port range in the IPv4 transport header field.  For example, rogue devices could bombard a public web server by launching TCP SYN ACK attack.  The victim will receive TCP SYN from random IPv4 source addresses at a rapid rate and deny TCP services to legitimate users. What is a properly authorized IPv4 address? What about an authorized transport protocol? If IPv6 address spoofing prevention is not in place, the AFTR should perform further sanity checks on the IPv6 address of incoming IPv6 packets. For example, it should check if the address has really been allocated to an authorized customer. How? Isn't address checking of this kind really just another form of spoofing prevention? Editorial: The source IPv4 is the RFC1918 addressed assigned by the Dual-Stack home router which is unique to each host behind the home gateway. ... address assigned ... or example, rogue devices could bombard a public web server by launching TCP SYN ACK attack.  The victim will receive TCP SYN from random IPv4 source addresses at a rapid rate and deny TCP services to legitimate users. Should this be ... launching *a* TCP SYN ACK attack? And maybe add a reference hree. Also, ... receive a TCP SYN packet from random ... Jari

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires