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

["Yiu L. Lee" <[e-mail]>]

Hi Jari,

Comments inline below:


On 8/17/10 8:43 AM, "Jari Arkko" <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires