Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Sep 2009 19:41:59 +0300

Hi, authors,

please prepare and submit a revision based on the feedback you have  
received until now. We need to move forward with this document.

Sandy hasn't responded since June 8. Take the initial feedback you  
have gotten from her into account, but I think it is unreasonable to  
wait longer for any additional feedback.

Lars

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Tue, 8 Sep 2009 10:03:04 -0700

Lars,

I have incorporated most of the comments and will check again to see if
I have left out anything. Actually after I am done with all the last
call comments, I'll send an email (esp copy the folks who had comments)
to see if I have addressed all of them, then will hit the submit button.

I am hoping to get this done by end of this week latest (earlier if
possible) Hope that is fine.

Thanks,
-Anantha 

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Tuesday, September 08, 2009 9:42 AM
> To: Anantha Ramaiah (ananth)
> Cc: Sandra Murphy; Mitesh Dalal (mdalal); IESG IESG; [email-masked]
> Subject: Re: draft-ietf-tcpm-tcpsecure
> 
> Hi, authors,
> 
> please prepare and submit a revision based on the feedback 
> you have received until now. We need to move forward with 
> this document.
> 
> Sandy hasn't responded since June 8. Take the initial 
> feedback you have gotten from her into account, but I think 
> it is unreasonable to wait longer for any additional feedback.
> 
> Lars

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sun, 13 Sep 2009 04:38:17 -0700

I figured out the reply to this email doidn't make it ( I was editing
the draft based on the feedback received)  

> From: Sandra Murphy [mailto:[email-masked]] 
> Sent: Monday, June 08, 2009 6:59 AM
> To: Anantha Ramaiah (ananth); Mitesh Dalal (mdalal)
> Cc: [email-masked]; [email-masked]
> Subject: draft-ietf-tcpm-tcpsecure
> 
> I've been on the road, so this is just a quick note to say 
> that I still have questions, with a promise of more full 
> answer when I get back to the office tomorrow.  All the 
> following done really from memory from a re-review yesterday. 
>  Just  so you know I haven't forgotten you.
> 
> About quoting text:
> 
> The example you point to of what each mitigation says is a good case. 
> (what is "rg"?)
> 
> You posit a case 1 and case 2.  This is a summary of what 793 
> says, not a quote.  793 spreads the discussion over 2 pages.  
> your case 1 is represented in a parenthetical remark in an 
> "otherwise" clause - hard to find.  And you have a typo in 
> the inequality.  And the case 2 in 793 is broken out over 
> three different groupings of states.  Do you mean the new ACK 
> to be generated in all three state groups?

Are you talking about RST/SYN mitigations ? If so the current text is
clear. The challenge ACK will be generated, pl note that the document
quotes the processing rules of the incoming segment and talks what mods
are suggested. 

> 
> About the stingency.
> 
> If UNA is 1000, Max.snd.wnd is 50, and the ack is 975, then 
> in 793, the ack is < UNA and so "it is ignored", in your 
> draft the ack is > UNA-max.snd.wnd so it is acceptable.

Ok, I have added more text to clarify this point. "Ignored"
 means the ACK value is ignored and the segment is processed as per the
other rules, hence ignored implies "accepted" and not dropped.

> 
> So your draft accepts more ACKs that 793.
> 
> Have I lost my ability to tell > from <?  Do you regard 
> accepting more ACKS as "more stringent"?

No, I think it is a mis-interpreation of ignored.

> 
> About the guidance to implementors.
> 
> It still looks to me like this guidance is only useful to 
> implementors who are implementing both the OS TCP stack *AND* 
> the application.  I.E., freebsd won't know whether this to 
> follow the guidance or not but cisco/juniper/etc will.

Not sure why such an inference is made.

> What is the "AS"?
Applicability statement (but I couldn't find the AS reference in the
draft, it is spelled out in full)
? 

-Anantha
> 
> About grammar checks:
> 
> And you did not miss email, I lost my marked up copy, so I've 
>  gone through for the grammar check again (don't think I 
> found all that many
> nits) and will send to you.
> 
> --Sandy
> 
> 
>

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 14 Sep 2009 11:22:47 -0400 (Eastern Daylight Time)

> the draft based on the feedback received)

That happens to you, too, huh?  Believe me, with my record of failed 
obligations lately, I'm really happy to have a chance to say "oh, that's 
OK" to someone.

The synopsis of this is:

How much rigor is needed in expressing the changes?

The cases (1) and (2) in section 3.2 have a typo.

What does the "it" in "it is ignored" mean?  As written, it looks like the 
ACK is ignored, but what I thought I saw in implementation was that the 
*segment* is ignored/dropped.  That makes a difference in comparing the 
new technique to the existing code.

How much does an application need to know about the TCP stack (and vice 
versa) for this to work (or work well)?

--Sandy

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 14 Sep 2009 08:38:21 -0700

> Sent: Monday, September 14, 2009 8:23 AM
> Cc: Mitesh Dalal (mdalal); [email-masked]; [email-masked]; Lars Eggert
> Subject: RE: draft-ietf-tcpm-tcpsecure
> 
> 
> 
> That happens to you, too, huh?  Believe me, with my record of 
> failed obligations lately, I'm really happy to have a chance 
> to say "oh, that's OK" to someone.

I was waiting for your other comments and wanted to reply all together.
Anyways, I have incorporated your comments along with all the other last
call comments received and posted the new version.

> The cases (1) and (2) in section 3.2 have a typo.

The text is quoted as per RFC 793. Which line is that are you referring
to ?

> 
> What does the "it" in "it is ignored" mean?  As written, it 
> looks like the ACK is ignored, but what I thought I saw in 
> implementation was that the
> *segment* is ignored/dropped.  That makes a difference in 
> comparing the new technique to the existing code.

Hmm.. Which implementation are you talking about?. ACK ignored != ACK
dropped. (I have clarfied that in the new version) As mentioned in 793,
the segment is continued for processing, all implementations do the same
today.

> versa) for this to work (or work well)?

It is a generic enhancement, although some applications sporting long
lived TCP connections tend to benefit when compared to short lived
applications (relatively speaking)

Well, if needed application can control this using knobs (socket options
etc.,) since these mitigations tend to look like being optional. These
are general purpose TCP mitigations and anyone can chose to turn these
on by default in their TCP stacks. 

Thanks for your review.

-Anantha
> >> I've been on the road, so this is just a quick note to say that I 
> >> still have questions, with a promise of more full answer 
> when I get 
> >> back to the office tomorrow.  All the following done really from 
> >> memory from a re-review yesterday.
> >> You posit a case 1 and case 2.  This is a summary of what 
> 793 says, 
> >> not a quote.  793 spreads the discussion over 2 pages.
> >> "otherwise" clause - hard to find.  And you have a typo in the 
> >> inequality.  And the case 2 in 793 is broken out over 
> three different 
> >> groupings of states.  Do you mean the new ACK to be 
> generated in all 
> >> three state groups?
> >
> > quotes the processing rules of the incoming segment and talks what 
> > mods are suggested.
> >
> >>
> >> About the stingency.
> >>
> >> If UNA is 1000, Max.snd.wnd is 50, and the ack is 975, 
> then in 793, 
> >> the ack is < UNA and so "it is ignored", in your draft the 
> ack is > 
> >> UNA-max.snd.wnd so it is acceptable.
> >
> >> Have I lost my ability to tell > from <?  Do you regard accepting 
> >> more ACKS as "more stringent"?
> >
> >> implementors who are implementing both the OS TCP stack *AND* the 
> >> application.  I.E., freebsd won't know whether this to follow the 
> >> guidance or not but cisco/juniper/etc will.
> >
> > draft, it is spelled out in full) ?
> >
> > -Anantha
> >>
> >> About grammar checks:
> >>
> >> And you did not miss email, I lost my marked up copy, so 
> I've  gone 
> >> through for the grammar check again (don't think I found all that 
> >> many

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 14 Sep 2009 08:39:55 -0700

Lars,
    I have submitted the next revision incorporating all the agreed upon
comments that have been received so far.
    I have checked all the comments received and have made the ones
which are agreed upon. Briefly :
 - new template 
- No IPR disclsoures on IETF documents, the RFC editor would do what is
needed. Brian clarified this.
- Addressed the last call comments by Brian Carpenter.
- Fernando's Last call comments agreed upon (added references to RFC
1948 and port randomization). 
- Sandra Murphy's comments whichever has been agreed upon.

Thanks,
-Anantha