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

"Anantha Ramaiah (ananth)" <> Sat, 15 August 2009 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08FB03A6BCC; Sat, 15 Aug 2009 09:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d85L88pTGgZk; Sat, 15 Aug 2009 09:36:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 135793A6BA4; Sat, 15 Aug 2009 09:36:14 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAG+AhkqrR7MV/2dsb2JhbAC4RIgtkEYFhBk
X-IronPort-AV: E=Sophos;i="4.43,386,1246838400"; d="scan'208";a="367903882"
Received: from ([]) by with ESMTP; 15 Aug 2009 16:36:18 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id n7FGaI4m023022; Sat, 15 Aug 2009 09:36:18 -0700
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id n7FGaIYp011609; Sat, 15 Aug 2009 16:36:18 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 09:36:18 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 15 Aug 2009 09:36:17 -0700
Message-ID: <>
In-Reply-To: <20090815004234.GN1043@Sun.COM>
Thread-Topic: [secdir] draft-ietf-tcpm-tcpsecure
Thread-Index: AcodQsijTDnttxM7QdmLnxlOaaJs0QAgZtfA
References: <> <20090814221222.GH1043@Sun.COM> <> <20090815004234.GN1043@Sun.COM>
From: "Anantha Ramaiah (ananth)" <>
To: Nicolas Williams <>
X-OriginalArrivalTime: 15 Aug 2009 16:36:18.0802 (UTC) FILETIME=[83F40D20:01CA1DC6]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2075; t=1250354178; x=1251218178; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20[secdir]=20draft-ietf-tcpm-tcpsecure |Sender:=20; bh=uxDvV+6oKeqnFfRxe5KNBNs3QsFdVnp/WIt3DOge7Mw=; b=IKEJUMwqqLum/NMZHXIiPrN7a/P6cGuoH9ocDDxDHyG6LUEv+LdBGKZrty t8QFeqQkrWxEGqZsqJ0mK8BM+EPqQvYuVQN49qx/2X8QL7zr4N+uaP1Mwu5D ZfEx0JYC6EPOIznVtj+HOXisAuG07byZLCz7lrN+dcrn7xXkMycLQ=;
Authentication-Results: sj-dkim-1;; dkim=pass ( sig from verified; );
Cc:, "Mitesh Dalal (mdalal)" <>,
Subject: Re: [secdir] draft-ietf-tcpm-tcpsecure
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 15 Aug 2009 16:36:15 -0000


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

> > 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.
> I'd like to hear from them.

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.
> OK.  Maybe this should be stated in the I-D.

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.

> Nico
> --