Subject: Re: [BEHAVE] Comments on draft-denis-icmpv6-generation-for-teredo-00

From: <[email-masked]>
Date: Wed, 16 Sep 2009 16:53:09 +0200

Hi Dave, behave,

We've updated this draft based on received feedback: http://www.ietf.org/id/draft-denis-icmpv6-generation-for-teredo-01.txt

1) We tried to tackle this by adding more text clarifying reply generation MUST only be done if middlebox is certainly on the return path and also clarification that host-specific relay function could otherwise break.

2) We'd like more clarification on this: how discovery is made easier when compared to attacker just sending ICMPv6 Echo Requests to various IPv6 peers out there? 

3) Yes, but blindly responding might make middlebox act as reflector on some attacks - i.e. there should be some sanity in ICMPv6 echo reply generation. Then again, this is about the same for any host/server and from that point of view useless to have in this document? Therefore we are consider dropping that piece of text out.

4) Right, but which one is worse: false negative or false positive reply of peer's liveness? The ICMPv6 anyway only tells the peer's lower layers are alive, but nothing about application layer stuff. 

We also added some text on CGA.

Best regards,

	Teemu

>-----Original Message-----
>From: ext Dave Thaler [mailto:[email-masked]] 
>Sent: 23 July, 2009 03:36
>To: Denis-Courmont Remi (Nokia-D/Helsinki)
>Cc: Savolainen Teemu (Nokia-D-MSW/Tampere); Behave WG
>Subject: RE: Comments on draft-denis-icmpv6-generation-for-teredo-00
>
>I forwarded the doc to our Teredo implementers and have some 
>additional feedback from them to pass along.
>
>1) The option for "Forced ICMPv6 Echo Reply generation for clients"
>mentioned in 2.1 is especially problematic in that it breaks 
>the concept of a host-specific relay (a dual-stack host that 
>is acting as a relay for itself).
>
>2) A security consideration is that this draft makes discovery 
>of Teredo relays much easier for an attacker, when then makes 
>it easier to mount attacks against them.
>
>3) Section 5 talks about rate limiting.  If you rate limit, 
>then you limit the usefulness because communication won't be 
>established.
>
>4) There are applications that consider ping replies as an 
>indicator of liveness (e.g., when picking which IP address to 
>use among a set, or whatever else).  Spoofing echo responses 
>will cause such apps to have expected behavior.
>
>
>> -----Original Message-----
>> From: Rémi Denis-Courmont [mailto:[email-masked]]
>> Sent: Wednesday, July 22, 2009 12:30 AM
>> To: Dave Thaler
>> Cc: Savolainen Teemu (Nokia-D-MSW/Tampere); Behave WG
>> Subject: Re: Comments on draft-denis-icmpv6-generation-for-teredo-00
>>
>> On Tuesday 21 July 2009 22:22:02 ext Dave Thaler wrote:
>> > Section 2.2 talks about translators sending (spoofed) echo replies 
>> > by default. However, if the translator is not guaranteed to be on 
>> > the
>> reverse
>> > path, e.g. in the case of multiple stateless translators, this is 
>> > dangerous. At minimum, the SHALL's need to be constrained to cases
>> where
>> > the translator is guaranteed to be on the reverse path.
>>
>> I don't disagree that a clarification would be good.
>>
>> However, I think it depends on how "a" translator is 
>defined. I think 
>> we can all agree that there has to be translation in both 
>paths. Then 
>> it depends whether one thinks of the translator as an abstract whole 
>> system or as a physical box between wires.
>>
>> Indeed, if the inbound and outbound boxes are distinct, stateless, 
>> unable to communicate with one another *and* topologically separate, 
>> there is a problem.
>>
>> > Section 2.3 states that firewalls SHOULD send (spoofed) 
>echo replies 
>> > to Teredo addresses.  This is again too strong.  If the firewall 
>> > would block incoming unsolicited packets from Teredo clients, then 
>> > it shouldn't send echo replies.  At minimum, the SHOULD 
>needs to be 
>> > constrained to a case where it would actually allow 
>packets through 
>> > from that address.
>>
>> Right.
>>
>> --
>> Rémi Denis-Courmont
>> Nokia Devices R&D, Maemo Software, Helsinki
>>
>
>