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

["Anantha Ramaiah (ananth)" <[e-mail]>]

 

> -----Original Message-----
> From: Sandra Murphy [mailto:[e-mail]] 
> Sent: Monday, September 14, 2009 8:23 AM
> To: Anantha Ramaiah (ananth)
> Cc: Mitesh Dalal (mdalal); [e-mail]; [e-mail]; Lars Eggert
> Subject: RE: draft-ietf-tcpm-tcpsecure
> 
> 
> 
> On Sun, 13 Sep 2009, Anantha Ramaiah (ananth) wrote:
> 
> >
> > I figured out the reply to this email doidn't make it ( I 
> was editing 
> > 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.

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 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.

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.

> 
> How much does an application need to know about the TCP stack 
> (and vice
> 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
> 
> --Sandy
> 
> >
> >> -----Original Message-----
> >> From: Sandra Murphy [mailto:[e-mail]]
> >> Sent: Monday, June 08, 2009 6:59 AM
> >> To: Anantha Ramaiah (ananth); Mitesh Dalal (mdalal)
> >> Cc: [e-mail]; [e-mail]
> >> 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
> >>
> >>
> >>
> >
>