Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt

["Smith, Donald" <[e-mail]>]

(coffee != sleep) & (!coffee == sleep)
[e-mail] gcia

> -----Original Message-----
> From: Anantha Ramaiah (ananth) [mailto:[e-mail]]
> Sent: Tuesday, May 18, 2010 2:32 PM
> To: Smith, Donald; [e-mail]; The IESG
> Subject: RE: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt
>
> Smith,
>     Comments inline..
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Smith, Donald
> > Sent: Tuesday, May 18, 2010 12:18 PM
> > To: '[e-mail] WG'; 'The IESG'
> > Subject: Re: [tcpm] Feedbackt on draft-ietf-tcpm-tcpsecure-13.txt
> >
> > First throughout this draft the authors refer to sequence
> > number checking where they really mean acknowledgement number
> > checking:( You can't quite do :g/sequence
>
> Incorrect. RST and SYN mitigtations talk about the sequence number
> checking.
> The ACK number is not relevant as far as the mitigation
> themselves are cocnerned. Data mitigation talks about the ACK
> number. We
> had added more text to make sure such ambiguity was removed when the
> data mitigation was discussed in response to WG comments.
>
>
> > number/s//acknowledgement number/g as in a few places it is
> > the senders sequence number they are discussing.
> > The authors also use "the exact expected sequence number" a lot.
> > I think they mean: last sent sequence number + the data length sent
>
> Nope, exact sequence number is RCV.NXT (which is the exact sequence
> number) RCV.NXT + RCV.WND -1 is the right edge.  Any sequence number
> which falls in this window is considered valid. These are all
> terminology borrowed from RFC 793 and we are not changing those.
ok.

>
> >
> > This looks a LOT like gonts draft but may be an attempt to
> > address just one issue identified here.
> >
> > http://tools.ietf.org/html/draft-gont-tcp-security-00#section-3.4
>
> What? TCP secure draft was first published in 2004/2005 after which
> followed informational RFC on "TCP spoofing attacks" , ICMP attacks,
> port randomization and then Gont's draft. TCP secure, FWIW, was an
> inspiration to all these drafts (with due acknowledgements to Watson's
> "slipping in the window" paper)
Ok
>
> Probably Gont's draft should refer this draft if not already doing so.
It references the 10th version of the draft.

>
> Were you not really following this document, this has been floating
> around for the last 5+ years in the IETF ?
I only joined this group a a year or so ago so no I haven't following this draft.

>
> >
> >
> > This is slightly incorrect. In window would include an exact
> > match for rcv.net+rcv.wnd so the right side should be =<.
> > The wording for how to do the challenge ack is a bit
> > difficult to follow too.
>
> Why? This has been reviewed by many folks and the way it is : i.e,
> quoting the RFC 793 text FIRST and then quoting the
> mitigations NEXT was
> easier to follow. I don't plan to change the WG decision.
>
> >
> >
> >
> >    3) If the RST bit is set and the sequence number does not exactly
> >       match the next expected sequence value, yet is within
> > the current
> >       receive window (RCV.NXT < SEG.SEQ < RCV.NXT+RCV.WND), TCP MUST
> >       send an acknowledgment (challenge ACK):
> >
> >       <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
> >
> > Ramaiah, et al.         Expires November 4, 2010
> >   [Page 9]
> > Internet-Draft                TCP Security
> >   May 2010
> >
> >       After sending the challenge ACK, TCP MUST drop the
> unacceptable
> >       segment and stop processing the incoming packet
> > further.  Further
> >       segments destined to this connection will be processed
> > as normal.
> >
> >
> >
> >
> >
> >
> >    3) If the RST bit is set and the sequence number does not exactly
> >       match the next expected sequence value, yet is within
> > the current
> >       receive window (RCV.NXT < SEG.SEQ =<
> RCV.NXT+RCV.WND), TCP MUST
> >       send an acknowledgment (challenge ACK):
>
> Again this is the RFC 793 language, we haven't changed it. (Pl see RFC
> 793 page 69, acceptability checks)
Ok. Reviewed (again) your correct the language is consistent.

>
> >
> >       <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
>
> The challenge ACK is what matters and you should be looking into.
>
> >
> >
> >
> >
> >
> >
> >
> > Ramaiah, et al.         Expires November 4, 2010
> >   [Page 9]
> >
> > Internet-Draft                TCP Security
> >   May 2010
> >
> >
> >       After sending the challenge ACK, TCP MUST silently drop
> > the in window
> >       but not exact match segment and stop processing it.
> Additional
> >       segments destined to this connection MUST be processed
> > as normal.
> >
> > That last line is really extraneous. You don't say what
> > happens to the packets before this event I am not sure you
> > have to say handle the next packet per normal behavior;) The
> > authors need to explain exactly what that challenge ACK looks like.
> > I think it is the same 4 tuple, ack = last sent ack, seq =
> > last sent seq (no data).
>
> Well, you can go on explaining each and everything, we had chosen to
> stick to the RFC 793 language, in other words, the intention is affect
> only the portion of RFC 793 and rest is exactly what RFC 793
> says. If we
> add additional text that would really add to the confusion. This was
> atleast the rationale and WG had agreed to such thinking w.r.t this
> draft.

People wrote books about rfc793 because it was a bit difficult to follow but
if that was the decision of the WG I withdraw my suggestions.

>
> >
> >
> >
> >
> > Still on page 9.
> > In all states except SYN-SENT, all reset (RST) segments are
> validated
> >    by checking their SEQ-fields [sequence numbers].  A reset
> > is valid if
> >    its sequence number exactly matches the next expected sequence
> >    number.  If the RST arrives and its sequence number
> field does NOT
> >    match the next expected sequence number but is within the window,
> >    then the receiver should generate an ACK.  In all other
> cases where
> >    the SEQ-field does not match and is outside the window,
> > the receiver
> >    MUST silently discard the segment.
> >
> >
> > Should be:
> > In all states except SYN-SENT, all reset (RST) segments are
> validated
> >    by checking their ACK-fields [acknowledgement numbers].  A
>
> Incorrect. It is the sequence number that needs to be validated first,
> please read RFC 793. (Page 37 RFC 793)
>
> > reset is valid if
> >    its acknowledgement number exactly matches the last sent
> > sequence number + the data length sent.
> >    If the RST arrives and its acknowledgement number field does NOT
> >    match the last sent sequence number + the data length sent
> > but is within the window,
> >    then the receiver SHOULD (or MUST?) generate an ACK.  In
> > all other cases where
> >    the ACK-field does not match and is outside the window,
> > the receiver
> >    MUST silently discard the segment.
> >
> >
> >
> > (coffee != sleep) & (!coffee == sleep)
>
> Not sure which of the above caused confusion ;-)
Perhaps a lack of coffee (or sleep:)

>
> -Anantha
>
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.