[savi] RFC6620 Page 15 - Data Trigger

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Tue, 06 May 2014 02:20 UTC

Return-Path: <leaf.yeh.sdo@gmail.com>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71131A049A for <savi@ietfa.amsl.com>; Mon, 5 May 2014 19:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0KisNwAmNgS for <savi@ietfa.amsl.com>; Mon, 5 May 2014 19:20:27 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4C11A0201 for <savi@ietf.org>; Mon, 5 May 2014 19:20:27 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id ey11so5247199pad.18 for <savi@ietf.org>; Mon, 05 May 2014 19:20:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=dn59f2HLsAYhivr4YtURu5wxbwppGCDHQOf9RL3dNeg=; b=B0e3GheEmz/yCt2jFBtZDaACOFetO0FJR/WAFPTF0EGieuYvzjjwDxAQLbH2LN1AVR w0KNi6oJ2WHElIzGuEClCXpyzKbSgDjVjYJDcSuHdmowpSFvCGv+CsGHSQ9aUlTubyYc 8qv1KYxQpmRa1xKLHiCOzTljg4u4K7vay9v8eT6h367hB7Kq5VpsV3yLYfbneKK1KXD2 VL8iGCpABuEikppUa+VxN4fifFnbizMsHjn7IALNny+hHL3w/y8qAgt0WUeSW1DKPCg2 RR2kTSJzRCsvRXo73TeyjxMKofSHjkLyKwcqtJCPJyGB8ndjezLwbgMtxASWnUhGXdye MLqA==
X-Received: by 10.66.250.161 with SMTP id zd1mr1006181pac.136.1399342823936; Mon, 05 May 2014 19:20:23 -0700 (PDT)
Received: from PC ([218.241.103.43]) by mx.google.com with ESMTPSA id lr3sm84786581pab.4.2014.05.05.19.20.21 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 May 2014 19:20:23 -0700 (PDT)
X-Google-Original-Message-ID: <009b01cf68d1$bad04a60$3070df20$@yeh.sdo@gmail.com>
From: Leaf Yeh <leaf.yeh.sdo@gmail.com>
To: 'SAVI Mailing List' <savi@ietf.org>, 'marcelo bagnulo braun' <marcelo@it.uc3m.es>, "'Eric Levy- Abegnoli (elevyabe)'" <elevyabe@cisco.com>
Date: Tue, 06 May 2014 10:20:17 +0800
Message-ID: <536846e7.637a420a.27dc.02df@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01CF6914.C8F38A60"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac9o0V57R5JaXpKkQKaDPzQwUOXmTw==
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/savi/0Uz5CVPysXYxmE2FdOgaCpyClIE
Subject: [savi] RFC6620 Page 15 - Data Trigger
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 06 May 2014 02:20:29 -0000

I read RFC6620 again, still have some questions on it.

 

Section 3.2.3 Page 15 @ the state of NO_BIND

<quote>

Upon the reception through a Validating Port (VP) of a DATA packet

      containing IPAddr as the source address, the SAVI device SHOULD

      execute the process of sending Neighbor Solicitation messages of

      the Duplicate Address Detection process ... The DAD_NS messages are
not

      sent through any of the ports configured as Validating Ports.  The

      DAD_NSOL messages are sent through Trusted Ports (but, of course,

      subject to usual switch behavior and possible MLD snooping

      optimizations)... The state

      is moved to TENTATIVE.  The LIFETIME is set to TENT_LT (i.e., LT:

      =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the

      Creation time is set to the current value of the local clock.

</quote>

 

It seems the DAD_NS are not sent to 'any of VP', but sent to TP, after the
VP received a data packet, whose source address are not in binding table of
the SAVI device.

 

If this data packet use the prefix assigned on this link, we don't expect
the DAD_NA from the TP.

If the data packet use any IID-interface ID, i.e. the 64 bits of the source
address, the SAVI switch will set up a binding entry for each source
address.

 

Then I guess we lost the finer-grained SAV here, and only can rely on the
SAVI (on-link) prefix list to filtering the 'transit traffic'. Right?

 

I mean the malicious host can create a huge number of *valid* source address
within the on-link prefix. What was the design philosophy here?

 

How about send DAD_NS to the VP received data packet for the double-check in
the above process?

 

 

Best Regards,

Leaf