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

From: Lars Eggert <[email-masked]>
Date: Fri, 14 Aug 2009 14:26:34 +0300

Hi,

what's going on with this draft? Is this still waiting for Sandy, or  
is the ball with the authors?

Lars

On 2009-7-9, at 10:06, Eggert Lars (Nokia-NRC/Espoo) wrote:

> Hi, Sandy,
>
> On 2009-6-8, at 16:59, Sandra Murphy wrote:
>> 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.
>
> the authors are still waiting to hear your additional questions.  
> Please let me know when we can expect them, so I know when I can  
> expect a revision from the authors.
>
> Thanks,
> Lars
>
>> 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?
>>
>> 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.
>>
>> 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"?
>>
>> 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.
>>
>> What is the "AS"?
>>
>> 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: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Fri, 14 Aug 2009 08:22:18 -0700

Hi Lars,
    I am still waitng for Sandy, but I am thinking I should go ahead and
probably submit what we have now (which I can do in a few days, since it
has been a while I looked at what I have and need to double check
whether everything is incorporated)
-Anantha 

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Friday, August 14, 2009 4:27 AM
> To: Sandra Murphy; Mitesh Dalal (mdalal); Anantha Ramaiah 
> (ananth); IESG IESG; [email-masked]
> Subject: Re: draft-ietf-tcpm-tcpsecure
> 
> Hi,
> 
> what's going on with this draft? Is this still waiting for 
> Sandy, or is the ball with the authors?
> 
> Lars
> 
> >> 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:
> >>
> >> 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?
> >>
> >> About the stingency.
> >>
> >> the ack is < UNA and so "it is ignored", in your draft the 
> ack is > 
> >> 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.
> >>
> >> What is the "AS"?
> >>
> >> About grammar checks:
> >>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 14 Aug 2009 17:12:22 -0500

The mitigations in this I-D are made SHOULD, SHOULD, and MAY (see
section 6, page 15).  But that means that a TCP implementation could
claim conformance while not implementing any of these mitigations.
Therefore they should be, IMO, MUST, MUST and MAY (or SHOULD).

Also, ISTM that the corner case described in section 4.2 can be avoided
by noting the retransmitted SYN and then sending a SYN+ACK to that, and
if an acknowledgement comes back then reset the old connection (and if
there's no listener to accept the new one, then reset it too).

Nico
--

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Fri, 14 Aug 2009 17:33:13 -0700

Hi Nico,

There was a big thread that went in TCPM some time back on this.
Initially the mitigations were tagged as "if you implement TCP secure
then all these are a MUST", such a statement gave a leeway for
implementers to chose whether or not they want to implement tcp-secure.
But some folks felt that since TCP secure has an IPR on it should
probably not have MUST in them at all, another argument was since TCP
secure is mostly useful only for long lived connections (like BGP), then
it may not be applicable to hosts and only applicable to routers. I
didn't (so as many others) didn't buy this argument, but since it was
not going anywhere Lars stepped up with the suggestion of applicability
statement to be added to this draft (I haven't seen any other TCP
related RFC which has an AS in it, FWIW) and the rest is history. I
seriously doubt whether the chairs/Lars/WG would like to fallback to
MUST/MUST/SHOULD.

In practice I have been given to understand that some vendors have
implemented these mitigations. Andre wanted to put these mitigations in
BSD as well, not sure about the current status. So, I am guessing if
folks are interested in adding robustness to their stacks in general and
TCP in particular, they would probably be interested in implementing
these mitigations.

Let me know if you need some text that needs to be added in the current
draft like for example add the reasoning why these mitigations are
chosen like this i.e, expand section 6 a little bit.

As far as the SYN corner case workaround we chose not to talk about the
fix for the same in the draft since the corner case exists in RFC 793
and nothing to do with the current SYN mitigation.

-Anantha

> From: Nicolas Williams [mailto:[email-masked]] 
> Sent: Friday, August 14, 2009 3:12 PM
> To: Sandra Murphy
> Cc: Anantha Ramaiah (ananth); Mitesh Dalal (mdalal); 
> [email-masked]; [email-masked]
> Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
> 
> The mitigations in this I-D are made SHOULD, SHOULD, and MAY 
> (see section 6, page 15).  But that means that a TCP 
> implementation could claim conformance while not implementing 
> any of these mitigations.
> Also, ISTM that the corner case described in section 4.2 can 
> be avoided by noting the retransmitted SYN and then sending a 
> SYN+ACK to that, and if an acknowledgement comes back then 
> reset the old connection (and if there's no listener to 
> accept the new one, then reset it too).
> 
> Nico
> -- 
>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 14 Aug 2009 19:42:35 -0500

> probably not have MUST in them at all, another argument was since TCP

If the issue is IPR then the WG/IETF could choose to make this RFC not a
Standards-Track RFC, but an FYI, and optionally drop the normative
RFC2119 language (or make those MUSTs; doesn't matter much to me, if the
RFC is to be Informational).

It'd be silly to make this a Standards-Track RFC with not a single
REQUIRED to implement feature in it -- all implementations of anything,
anywhere, could then claim to be compliant.  If there was at least one
REQUIRED to implement then you could choose to make other encumbered
features RECOMMENDED, or OPTIONAL.  But no RTI feature at all makes no
sense to me.

> it may not be applicable to hosts and only applicable to routers. I

So what?  Implementors who don't care for this feature wouldn't be bound
to implement it just because this RFC says it's a MUST.  Implementors
who don't implement it would just not be compliant with this RFC, but
nothing says they have to be.

> seriously doubt whether the chairs/Lars/WG would like to fallback to

I'd like to hear from them.

> and nothing to do with the current SYN mitigation.

OK.  Maybe this should be stated in the I-D.

Nico
--

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 15 Aug 2009 09:36:17 -0700

>
> 
> > secure is mostly useful only for long lived connections (like BGP), 
> > then it may not be applicable to hosts and only applicable 
> to routers. 
> > I
> 
> So what?  Implementors who don't care for this feature 
> wouldn't be bound to implement it just because this RFC says 
> it's a MUST.  Implementors who don't implement it would just 
> not be compliant with this RFC, but nothing says they have to be.

Well, we did argue this point before.

> > not going anywhere Lars stepped up with the suggestion of 
> > applicability statement to be added to this draft (I 
> haven't seen any 
> > other TCP related RFC which has an AS in it, FWIW) and the rest is 
> > history. I seriously doubt whether the chairs/Lars/WG would like to 
> > fallback to MUST/MUST/SHOULD.
> 

Sure, but if you can also suggest some text (either in the AS section or
in section 6) which can probably make the implementers more comfortable
and also can make look the compliance story healhier we can consider
adding such a text and take care of this issue. As an FYI, I want to
stress that the draft has been around for a long time before reaching
last call and I would prefer not to move backwards. That said, if the
consensus turns out to be changing the mitigation stengths as per your
suggestion, I am fine with that too!

> 
> > As far as the SYN corner case workaround we chose not to talk about 
> > the fix for the same in the draft since the corner case 
> exists in RFC 
> > 793 and nothing to do with the current SYN mitigation.
> 

The draft already covers it in section 4.2. "This corner case is a
result of the [RFC0793] specification and is
not introduced by these new requirements."  

Do you see the need for more clarification?, if so pl feel free to send
some text.

-Anantha

---

From: Lars Eggert <[email-masked]>
Date: Sun, 16 Aug 2009 10:54:37 +0300

Hi,

as Anantha said, the process by which the WG arrived on what's in the  
current document was slightly painful for all involved.

If there are changes proposed, please discuss them on the WG list.  
Because this specific issue was so controversial, any change here  
needs to be vetted by the WG consensus process.

Lars

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 16 Aug 2009 18:41:33 -0500

> needs to be vetted by the WG consensus process.

I don't have the energy for that.

There are ways to deal with IPR.  Is this one of them?  I fail to
understand what a Standards-Track RFC means that has no required to
implement features.  Surely the IESG will wonder too.  And if not, would
that be because the issue has been settled before and we do know what
such an RFC "means"?  If so, please let me know.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 16 Aug 2009 18:36:48 -0700

At 7:42 PM -0500 8/14/09, Nicolas Williams wrote:
>anywhere, could then claim to be compliant. 

The draft in question normatively relies on the definitions in RFC 2119 and, because it is slated for standards track, RFC 2026.

Any implementation of any type of RFC, not just standards track RFCs, can claim whatever it wants. 'Twas ever thus.

If you want to update RFC 2026 to deal with the issue of standards track documents with no RFC 2119 MUST statements, that's fine. However, doing so should not affect Internet Drafts while the IETF goes through yet another process on process.