Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...)

Warren Kumari <warren@kumari.net> Mon, 15 August 2011 15:12 UTC

Return-Path: <warren@kumari.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCED521F8A69 for <v6ops@ietfa.amsl.com>; Mon, 15 Aug 2011 08:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.122
X-Spam-Level:
X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtniMBo4grRW for <v6ops@ietfa.amsl.com>; Mon, 15 Aug 2011 08:12:27 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id DE87321F8B61 for <v6ops@ietf.org>; Mon, 15 Aug 2011 08:12:26 -0700 (PDT)
Received: from dhcp-172-19-118-113.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id DB6F11B4153B; Mon, 15 Aug 2011 11:13:11 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com>
Date: Mon, 15 Aug 2011 11:13:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE3DF572-704C-4507-AB6F-F5960971838F@kumari.net>
References: <1313420245.20792.YahooMailClassic@web2818.biz.mail.ne1.yahoo.com>
To: nalini.elkins@insidethestack.com
X-Mailer: Apple Mail (2.1084)
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-elkins-6man-ipv6-diagnostic-header (Was: draft minutes ietf 81, 3 meetings...)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2011 15:12:27 -0000

On Aug 15, 2011, at 10:57 AM, nalini.elkins@insidethestack.com wrote:

> Shane,
> 
> 
>> 
>> Have you taken a look at flow-spec for IPv4:
>> http://tools.ietf.org/html/rfc5575
>> ... and, flow-spec for IPv6:
>> http://tools.ietf.org/html/draft-ietf-idr-flow-spec-v6-00
>> (Both the RFC and I-D are within the IDR WG).
>> 
>> In summary, using flow-spec one can define an ACL that then
>> get distributed across all routers within an ASN, via BGP,
>> that can then be used to count matching packets, log packet
>> header information, etc.  It's up to the operator to
>> decide what ACL to be applied and what 'action' (logging,
>> counting, etc.) to be taken for packets that match a given
>> 'rule'.  
>> 
>> From where I'm sitting, this seems like it might already
>> solve the problem you're having, without having to invent a
>> wholly new IPv6 Destination Header Option.  So, I would
>> like to know if you have taken a look at flow-spec and, if
>> so, why it was ruled out?
> 
> Certainly an interesting set of RFCs but a few questions I would have:
> 
> 1.  What if BGP is not being used?
> 
> 2.  What about matching packets at non-router devices (that is, hosts)

If you are at the host you can simply match whatever tuple you are interested in and log the entire packet, and then do whatever analysis after the fact.

> 
> 3.  I believe what we need in diagnostics is the entire packet not just a logging that such a packet existed.  For example, the problem we are looking for may be in the body of the protocol data.  Ex. a problem with FTP.  
> So, we would need the entire packet as captured by a packet analyzer rather than a log that says 'a packet from dest x to source y was sent'.  I do not imagine that the log is going to keep the entire packet.  Am I missing something?

So:
A: Capture at the end host
or
B: Capture on the network if you really must (although having taps on the physical layer causes most security minded operators to get the heebie-jeebies) and match upon tuples...

W
> 
> 
>> 
>> -shane
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>