Re: [savi] Potential issue for all SAVI mechanisms?

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 22 June 2011 00:17 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE18611E80A7 for <savi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.766
X-Spam-Level:
X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5riDBaXeIuS for <savi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:17:40 -0700 (PDT)
Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id EF01E11E8088 for <savi@ietf.org>; Tue, 21 Jun 2011 17:17:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D204C324657F; Tue, 21 Jun 2011 17:17:09 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.154.181.49] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 3B5F73246570; Tue, 21 Jun 2011 17:17:09 -0700 (PDT)
Message-ID: <4E013482.3080405@joelhalpern.com>
Date: Tue, 21 Jun 2011 20:17:06 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Jun Bi <junbi@cernet.edu.cn>
References: <BANLkTi=Te8AS+sdhOGtCvgFqa48dHc80WQ@mail.gmail.com> <F29187458BA64F46BE7069B37C4CF19D@junbiVAIOz138>
In-Reply-To: <F29187458BA64F46BE7069B37C4CF19D@junbiVAIOz138>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: SAVI Mailing List <savi@ietf.org>, Jean-Michel Combes <jeanmichel.combes@gmail.com>
Subject: Re: [savi] Potential issue for all SAVI mechanisms?
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2011 00:17:44 -0000

I do not think this is a sufficient answer.  Whether the device is a 
switch or a router, reassembling or maintaining packet state across 
fragements is a non-trivial undertaking.

I can imagine some kludges to get around this, but they have broader 
impact than just SAVI.  (For example, rejecting first packets that do 
not have enough information to determine whether or not they are 
claiming to be RAs or DHCP replies.)

Yours,
Joel

On 6/21/2011 9:56 AM, Jun Bi wrote:
> Hi Jean-Michel,
>
> What we are talking about "savi switch" is a 2.5 layer switch (layer 2
> switch in data plan with layer 3-aware in controll/management plan).
> So what I know from switch vendor is that the 2.5 layer switch chip or
> the stronger CPU can handel it.
> For example, the chip can recongnize the Protocol ID field of IP packets
> to recongznie HDCP or NDP packets (even in fragments),
> then copy them to switch CPU. The CPU can handle it.
>
> The SAVI switch has been really implmented and deployed, so I did really
> see any problem in real network.
> BTW, it seems that SAVI switch doesn't snoop and process RA packets for
> binding, so maybe RA packet is different.
>
> thanks,
> Jun Bi
>
> -----原始邮件----- From: Jean-Michel Combes
> Sent: Tuesday, June 21, 2011 9:37 PM
> To: SAVI Mailing List
> Subject: [savi] Potential issue for all SAVI mechanisms?
>
> Hi,
>
> Maybe you already know that there is a discussion on v6ops/6man MLs
> about RA Guard evasion (cf.
> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html).
> One of the methods to perform this evasion is fragmentation: it seems
> that a L2 device would not be able to re-assemble all the fragments
> without an important extra-cost and so would not be able to determine
> whether or not the message is a Router Advertisement (cf.
> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html).
>
> Knowing that:
> (1) In common use-case, SAVI device is a L2 device
> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection
>
> I am wondering whether or not fragmentation would not impact strongly
> SAVI specifications too: any fragmented NDP/SEND/DHCP message could
> not update correctly the Binding Table and so what would be the
> consequences?
>
> I would appreciate comments from WG members, especially
> implementors/manufacturers, about this.
>
> Thanks in advance for your replies.
>
> Best regards.
>
> JMC.
> _______________________________________________
> savi mailing list
> savi@ietf.org
> https://www.ietf.org/mailman/listinfo/savi
> _______________________________________________
> savi mailing list
> savi@ietf.org
> https://www.ietf.org/mailman/listinfo/savi