Re: AD review of draft-krishnan-v6ops-teredo-update

[Suresh Krishnan <[e-mail]>]

Hi Jari,
   Thanks for the comments. I will address them in a new version by the 
end of this week.

Thanks
Suresh

On 10-04-27 04:33 AM, Jari Arkko wrote:
> I have reviewed this draft and have the following comments. In general, 
> the draft is in good shape and can move forward. I have two small 
> technical issues and a few minor editorial ones. Nevertheless, I have 
> decided to initiate last call, but I would appreciate a quick document 
> update in the next few days to correct these issues.
> 
> Technical:
>> Teredo Client: A node that has access to the IPv4 Internet and wants
>> to gain access to the IPv6 Internet.
>>   
> There are lots of such nodes, but not all of them are Teredo clients, 
> i.e., implement the Teredo protocol... please correct the definition.
> 
>> Opening a hole in an enterprise firewall
>> [I-D.ietf-v6ops-tunnel-security-concerns <http://tools.ietf.org/html/draft-krishnan-v6ops-teredo-update-06#ref-I-D.ietf-v6ops-tunnel-security-concerns>]: Teredo is NOT RECOMMENDED
>> as a solution for managed networks.  Administrators of such networks
>> may wish to filter all Teredo traffic at the boundaries of their
>> networks.
>>   
> 
> I'm not sure the term "managed networks" is a correct one here. There 
> are many types of managed networks, some care about blocking Teredo and 
> some would not. Suggested rewrite:
> 
> "Opening a hole in an enterprise firewall 
> [I-D.ietf-v6ops-tunnel-security-concerns]: Teredo is NOT RECOMMENDED as 
> a solution for networks that wish to implement strict controls for what 
> traffic passes to and from the Internet.  Administrators of such 
> networks may wish to filter all Teredo traffic at the boundaries of 
> their networks."
> 
> (Also, speaking personally, I may not completely agree with the 
> conclusions from draft-ietf-v6ops-tunnel-security-concerns that 
> inspection of tunneled traffic is always hard and inefficient. I think 
> there is some room to allow firewalls to inspect tunneling traffic on 
> top of well-known and established tunneling protocols such as Teredo.)
> 
> Editorial:
> 
>> Teredo IPv6 Address: An IPv6 address that starts with the prefix
>> 2001:0000:/32 and is formed as specified in [RFC4380] section 2.14 <http://tools.ietf.org/html/rfc4380#section-2.14>.
>>   
> 
> Wouldn't Section 4 be a better reference here?
> 
>> Teredo addresses are structured and some of the fields contained in
>> them are fairly predictable.  This can be used to better predict the
>> address.
>>   
> 
> I would rewrite the second sentence (which currently doesn't say much) 
> as follows: "This makes it easier to predict an address, opening a 
> (small) vulnerability."
> 
>>    open on a IPv4 address, prior to trying to form a Teredo address for
> s/on a/on an/
> 
>> 4. Acknowledgments
>> ....
>> 5. Security Considerations
> 
> I think it would be better if all the technical parts of the document 
> were explained first, followed by the acknowledgment section. That is, I 
> think Section 5 would come more naturally before Section 4.
> 
> Jari