Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-tcp-antispoof-05.txt (Ends 2 Feb 2007)

From: Ted Faber <[email-masked]>
Date: Fri, 2 Feb 2007 10:54:15 -0800

On Fri, Jan 26, 2007 at 09:47:42AM -0800, Ted Faber wrote:
> On Wed, Jan 17, 2007 at 05:24:41PM -0800, Ted Faber wrote:
> > Hi.
> > 
> > As we mentioned in San Diego, the anti-spoof document is ready for a
> > second last call.  We're primarily checking to see that issues brought
> > up in the first WGLC have been addressed.  You can find much of that
> > discussion starting here:
> > 
> > http://www1.ietf.org/mail-archive/web/tcpm/current/msg01890.html
> > 
> > The draft is available from 
> > 
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-antispoof-05.txt
> > 
> > Comments (including positive ones, please) to the list.
> > 
> > This WGLC will end 2 Feb 2007 - a little more than 2 weeks from now.
> 
> Just a reminder: this WGLC has one week left.  I've only seen one
> message about the draft.  Passing a WGLC requires some reaction from the
> group.  If you're interested in seeing this work done and believe that
> this document represents a reasonable consensus, please speak up.  And,
> of course, if you see problems with the draft, also speak up.

One more heads up.  Today (2 Feb 2007) is the last day of this WGLC.
If you've been thinking hard or meaning to get to this, please send
something today.

Thanks.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Pekka Savola <[email-masked]>
Date: Fri, 2 Feb 2007 21:48:56 +0200 (EET)

> If you've been thinking hard or meaning to get to this, please send

(As I already said earlier, I believe this is a document that should 
be IETF Last Called even if doing so is not required by RFC2026.)

I've had some comments on earlier versions of the draft.  I've now 
checked those.  The document isn't as explicit as I'd have liked 
particularly in section 3.2.1, but I find it mostly acceptable.  I 
object to the conclusion of section 3.2.1 which was not updated based 
on the latest discussion:

   As a result, address filtering is not a local solution that can be
    deployed to protect communicating pairs, but rather relies on a
    distributed infrastructure of trusted gateways filtering forged
    traffic where it enters the network.  It is not feasible for local,
    incremental deployment, and relies heavily on distributed
    cooperation.  Although useful to reduce the load of spoofed traffic,
    it is insufficient to protect particular connections from attack
    [29].

Specifically the second sentence seems somewhat assumptive of the 
communication patterns and usefulness thereof for the endpoints, and 
the resulting conclusion in the third sentence is also assumptive. 
Anyone will agree that address filtering is not a _complete_ solution 
for every communication a random host might want to do, but whether it 
protects some particular connections from attack depends on how those 
connections are situated related to the address filtering border(s) 
[and what filtering has been configured there] and where the attacker 
is (as is now slightly expanded in the 2nd paragraph).

Earlier, I suggested the following replacement text (for -02):

    As a result, address filtering can be deployed locally but it only
    protects communications where both parties are local.  Therefore, the
    larger the address filtering border is, the more extensive the protection
    is.  This is a particularly useful means of protection for specific kinds
    of sessions which are known to be local.  However, as address filtering
    is performed in the network by trusted gateways, the users not know
    whether the filtering exists or not.  Hence, the users cannot rely on it
    in general and other mechanisms for protection must be used as well.
    Still, address filtering is very useful to protect specific kinds of
    communications (e.g., network management, most router-to-router
    communication, etc.).

But a smaller delta to the current text might also be OK even if it is 
less explicit, for example:

    As a result, address filtering is not a local solution that can be
    deployed to protect communicating pairs, but rather relies on a
    distributed infrastructure of trusted gateways filtering forged
    traffic where it enters the network.  It is not feasible as a
    general solution due to the lack universal deployment, but
    may be applicable to connections among those inside the protected
    border in some scenarios.  Applying filtering also reduces
    the load of spoofed traffic [29].

As another comment, Section 3.2.1 also refers to RFC3682 section 5.1 
for TTL-security discussion, and also mentions BITW tunnels. 
draft-ietf-rtgwg-rfc3682bis would be a better reference here as the 
security properties of TTL-based security and particularly use with 
tunnels has been greatly expanded.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Feb 2007 22:41:35 -0800

Hi, all,

Pekka Savola wrote:
> (As I already said earlier, I believe this is a document that should be 
> IETF Last Called even if doing so is not required by RFC2026.)

I'm not sure every document wouldn't fall into that category; I disagree 
that this particular document should be treated uniquely.

> object to the conclusion of section 3.2.1 which was not updated based on 
> the latest discussion:
> 
> communication patterns and usefulness thereof for the endpoints, and the 
> resulting conclusion in the third sentence is also assumptive. Anyone 
> will agree that address filtering is not a _complete_ solution for every 
> communication a random host might want to do, but whether it protects 
> some particular connections from attack depends on how those connections 
> are situated related to the address filtering border(s) [and what 
> filtering has been configured there] and where the attacker is (as is 
> now slightly expanded in the 2nd paragraph).

I entirely agree that filtering works in some cases, depending on the 
specifics of where it is deployed and what the nature of the attack is. 
For example, if you're in control of all the distributed locations where 
you depend on filtering, or the topology is such that they're not very 
distributed, things get simpler. However, that doesn't seem a useful 
nuance to point out, IMO.

>    the load of spoofed traffic [29].

I agree with the second sentence, which might be useful to include. As 
to the last sentence, this document focuses on endpoint mechanisms for 
defense, and doesn't address upstream load reduction.

> As another comment, Section 3.2.1 also refers to RFC3682 section 5.1 for 
> TTL-security discussion, and also mentions BITW tunnels. 

Thanks for pointing that out. Since the ID hasn't been published yet, 
it's probably useful to cite both documents on that point.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

---

From: Pekka Savola <[email-masked]>
Date: Sat, 3 Feb 2007 08:50:09 +0200 (EET)

>>     it is insufficient to protect particular connections from attack
...
> I agree with the second sentence, which might be useful to include. As to the 
> last sentence, this document focuses on endpoint mechanisms for defense, and 
> doesn't address upstream load reduction.

I don't care about the last sentence, and it could be removed or 
reworded.  It was just an attempt to rephrase the last sentence in the 
original (above) so that reference [29] is preserved.

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Feb 2007 22:52:53 -0800

OK - I think we have converged on this, right?

---

From: Lars Eggert <[email-masked]>
Date: Sat, 3 Feb 2007 11:31:40 +0200

On 2007-2-3, at 8:41, ext Joe Touch wrote:
> Pekka Savola wrote:
>> (As I already said earlier, I believe this is a document that  
>> should be IETF Last Called even if doing so is not required by  
>> RFC2026.)
>
> I'm not sure every document wouldn't fall into that category; I  
> disagree that this particular document should be treated uniquely.

IETF Last Calls for non-standards-track docs are common, especially  
when a document should be brought to the attention to the wider  
community due to its importance or impact. (For example, we IETF-last- 
called QuickStart and the fragmentation-harmful documents in the  
recent past.)

I agree with Pekka that antispoof is sufficiently important that the  
wider community should be notified of its availability for review.

Lars

---

From: Ted Faber <[email-masked]>
Date: Mon, 5 Feb 2007 10:38:09 -0800

On Wed, Jan 17, 2007 at 05:24:41PM -0800, Ted Faber wrote:
> up in the first WGLC have been addressed. 

After looking over the discussion, the chairs feel that (assuming
Pekka's issues have been suitably addressed) this document has passed
WGLC.  We'll plan to make the revisions that address Pekka's comments
and then advance this to the IESG.

Given Pekka's interest and Lars's support for an IETF last call, I
believe we'll request one.

Thanks again for your input.

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Feb 2007 11:11:03 -0800

> WGLC.  We'll plan to make the revisions that address Pekka's comments

Also Afred Hoenes, who pointed out a number of editorial errors I can
catch at this point, and a nominal tech issue as well. I'll post a
summary of changes to the list as soon as I get confirmation of
acceptance from them.

> ------------------------------------------------------------------------
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Feb 2007 23:23:52 -0800

The following is a summary of feedback from the last call:

- Wes Eddy endorsed the doc

- Alfred Hoenes provided detailed input

	- numerous typos were addressed

	- sec 2.4 had an error, where the attack takes only 20 seconds
	for a 1Mbps link; this description was updated to indicate that
	such an attack is less likely primarily because of port
	randomization, and now cites Larsen/Gont's recent I-D

	- sec 5.2 AH was corrected from "deprecated" to
	"being phased out", and now cites 4301

	- requested addressing NATs
	a paragraph was appended to the security considerations section

- Lars Eggert provided input

	- also noticed the sec 2.4 error above

- Pekka Savola provided input

	- sec 3.2.1, paragraph 3 was reworded according to his
	suggested text on filtering

	- draft-ietf-rtgwg-rfc3682bis-09.txt was added to the
	references where BITW was discussed

- the document was updated with revised BCP 78 boilerplate

All the above modifications were confirmed as sufficient by the parties
above. The revised document, -06, has already been submitted to the I-D
repository (and passed IDnits). It should be available shortly; until
then, it is available at:
http://www.isi.edu/touch/pubs/draft-ietf-tcpm-tcp-antispoof-06.txt

Joe