Hi Jari, Comments inline below:
On 8/17/10 8:43 AM, "Jari Arkko" <[email protected]> wrote: > 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. > > [YL] Do you suggest to put some wording about UPnP-IGD in Section 8? > > What happens if two B4s are chained together, both using the reserved address > range? > > [YL] I am not sure what do you mean by ³chaining the two B4s together². Can > you elaborate? >> >> 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. > > [YL] This logging requirement for this specification always focuses on the > AFTR. I think we can make this clear that the AFTR should log the binding > information to support lawful audit. > >> 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? > > [YL] In fact, this information has to be provisioned in the AFTR. What we > suggested here is at minimum, the AFTR should accept packets sourced only from > RFC1918 and the new IANA reserved address range. > >> 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? > > [YL] If we change the word ³authorized² to ³provisioned². Is this more clear > to you? >> >> 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? > > [YL] What we tried to say is the AFTR must implement ACL type checking to only > accept the IPv6 address range defined in the ACL. > > Editorial: > >> >> The source IPv4 is the RFC1918 <http://tools.ietf.org/html/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 ... > > [YL] I will add RFC4987 to the reference. > > Thanks, > Yiu > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
