From internet-drafts@ietf.org Wed Apr 3 00:52:09 2013 Return-Path: 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 02AC721F870F; Wed, 3 Apr 2013 00:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 XdTOccr+1EvP; Wed, 3 Apr 2013 00:52:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0BE21F852A; Wed, 3 Apr 2013 00:52:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130403075208.3728.95426.idtracker@ietfa.amsl.com> Date: Wed, 03 Apr 2013 00:52:08 -0700 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-send-09.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 07:52:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvements Wo= rking Group of the IETF. Title : SEND-based Source-Address Validation Implementation Author(s) : Marcelo Bagnulo Alberto Garcia-Martinez Filename : draft-ietf-savi-send-09.txt Pages : 31 Date : 2013-04-03 Abstract: This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-send There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-send-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-savi-send-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Apr 3 07:03:38 2013 Return-Path: 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 7A53421F8A8A; Wed, 3 Apr 2013 07:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 DHKmP9+MfZHS; Wed, 3 Apr 2013 07:03:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 946F521F8A91; Wed, 3 Apr 2013 07:03:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130403140337.2744.18377.idtracker@ietfa.amsl.com> Date: Wed, 03 Apr 2013 07:03:37 -0700 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-threat-scope-07.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 14:03:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvements Wo= rking Group of the IETF. Title : SAVI Threat Scope Author(s) : Danny McPherson Fred Baker Joel M. Halpern Filename : draft-ietf-savi-threat-scope-07.txt Pages : 24 Date : 2013-04-03 Abstract: Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-threat-scope-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-savi-threat-scope-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jeanmichel.combes@gmail.com Wed Apr 3 08:42:16 2013 Return-Path: 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 98F9021F8F32; Wed, 3 Apr 2013 08:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 h6mJgy7s8zvA; Wed, 3 Apr 2013 08:42:15 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A265321F8F2E; Wed, 3 Apr 2013 08:42:14 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hr17so3770778wib.17 for ; Wed, 03 Apr 2013 08:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=Ann4Skm+VvmNRynhrhhVMvrFNrOR4/XZ09+V71pKCGM=; b=rgF+178GcWLKgni0SE4SMLZKpqThxaYBHBDBogKb2lwmYNFd6IF8hTXk9uGSvRV3nJ vv2HKLoX3HOyWdzCotGjGcLWQDFzTbrkt1itxnKReK9PHIPVQd2eqEIBJTwdnvvqX+B1 SnzyVQeRvb2YBQh7vc3exGR7AcrcPtN9ad0E0QstUqEIgtIXuFyLcSkrplEV1CobAtOW nW0Uay88dbT1w9V/VBX3xv/96Y7KptM9zzWOP6ehFbVHvKs/ye2L8TBtKjeXQKKDdcTk xx8ulgCJ7sNlDZRFklLpd3OPmR4ofsuOv7lPqaCVtutV4N4LSVoyAPYDm7rT8yEm42dR bmUg== MIME-Version: 1.0 X-Received: by 10.180.90.35 with SMTP id bt3mr5095360wib.4.1365003731843; Wed, 03 Apr 2013 08:42:11 -0700 (PDT) Received: by 10.194.234.66 with HTTP; Wed, 3 Apr 2013 08:42:11 -0700 (PDT) Date: Wed, 3 Apr 2013 17:42:11 +0200 Message-ID: From: Jean-Michel Combes To: iesg-secretary@ietf.org Content-Type: multipart/alternative; boundary=f46d043c80e68dc1be04d976b293 Cc: int-ads@tools.ietf.org, SAVI Mailing List , "savi-chairs@tools.ietf.org" Subject: [savi] Publication request for "SEND-based Source-Address Validation Implementation" (draft-ietf-savi-send-09) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:42:16 -0000 --f46d043c80e68dc1be04d976b293 Content-Type: text/plain; charset=ISO-8859-1 Dear Secretary, This is a request to publish draft-ietf-savi-send-09 as Standard track RFC. Please find below the I-D write-up. Thanks in advance. Best regards, JMC. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard is being requested. Based on RFC 2026 and RFC 6410, this is the proper type of RFC. This type of RFC is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used. Working Group Summary: There is SAVI WG consensus behind the document. Document Quality: This document was thoroughly reviewed by Ana Kukec, Tony Cheneau, Greg Daley and Jean-Michel Combes. Personnel: The Document Shepherd is Jean-Michel Combes (jeanmichel.combes at gmail.com), as savi WG chair. The Responsible Area Director is Ted Lemon (ted.lemon at nominum.com) (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. During his review, the Document Shepherd focused on these main points: - Compliance with "Source Address Validation Improvement Framework" document (draft-ietf-framework-06) - Compliance with issues raised during the IESG review for "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses" (RFC 6620) - Compliance with SEND specifications (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document Shepherd have no concerns about the depth or breadth of the reviews that have been performed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. As the csi WG is closed now, the document Shepherd thinks there is no more place to request a review from SEND experts. So, the document Shepherd thinks this document doesn't need review from a particular or from broader perspective. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. (13) Have all references within this document been identified as either normative or informative? (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. --f46d043c80e68dc1be04d976b293 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Secretary,

This= is a request to publish draft-ietf-savi-send-09 as Standard track RFC. Ple= ase find below the I-D write-up.

Thanks in advance.

Best regards,

JMC.


(1) What type of RFC is being requested (BCP, Proposed St= andard, =20 Internet Standard, Informational, Experimental, or Historic= )? Why =20 is this the proper type of RFC? Is this type of RFC indica= ted in the =20 title page header?

Proposed Standard is being re= quested.

Based on RFC 2026 and RFC 6410, this is the proper type of R= FC.

This type of RFC is indicated in the title page header.


(2) The IESG approval announcement includes a Document Annou= ncement =20 Write-Up. Please provide such a Document Announcement Write= -Up. Recent =20 examples can be found in the "Action" announcemen= ts for approved =20 documents. The approval announcement contains the following= sections:

Technical Summary:

This memo describes SEND SAVI, a mechanism to provide= source address validation using the SEND protocol. The proposed mechanism = is intended to complement ingress filtering techniques to provide a finer g= ranularity on the control of the source addresses used.

Working Group Summary:

There is SAVI WG consensus behind the document.

Document Quality:

This document was thoroughly reviewed by Ana Kukec, T= ony Cheneau, Greg Daley and Jean-Michel Combes.

Personnel:

The Document Shepherd is Jean-Michel Combes (jeanmichel.combe= s at gmail.com), as savi WG chair.

The Responsible Area Director is Ted Lemon (ted.lemon at nominum.com)

(3) Briefly describe the review of this document that was= performed by =20 the Document Shepherd. If this version of the document is = not ready =20 for publication, please explain why the document is being f= orwarded to =20 the IESG.

During his review, the Document Shephe= rd focused on these main points:

- Compliance with "Source Addre= ss Validation Improvement Framework" document (draft-ietf-framework-06= )

- Compliance with issues raised during the IESG review for "FCFS SA= VI: First-Come, First-Served Source Address Validation Improvement for Loca= lly Assigned IPv6 Addresses" (RFC 6620)

- Compliance with SEND s= pecifications

(4) Does the document Shepherd have any concerns about the depth or =20 breadth of the reviews that have been performed?

The document Shepherd have no concerns about the depth or breadth of the r= eviews that have been performed.

(5) Do portions of the document need review from a partic= ular or from =20 broader perspective, e.g., security, operational complexity= , AAA, DNS, =20 DHCP, XML, or internationalization? If so, describe the rev= iew that =20 took place.

As the csi WG is closed now, the doc= ument Shepherd thinks there is no more place to request a review from SEND = experts. So, the document Shepherd thinks this document doesn't need re= view from a particular or from broader perspective.

(6) Describe any specific concerns or issues that the Doc= ument Shepherd =20 has with this document that the Responsible Area Director a= nd/or the =20 IESG should be aware of? For example, perhaps he or she is = uncomfortable =20 with certain parts of the document, or has concerns whether= there really =20 is a need for it. In any event, if the WG has discussed tho= se issues and =20 has indicated that it still wishes to advance the document,= detail those =20 concerns here.

The

(7) Has each author confirmed that any and all appropriat= e IPR =20 disclosures required for full conformance with the provisio= ns of BCP 78 =20 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this= document? =20 If so, summarize any WG discussion and conclusion regarding= the IPR =20 disclosures.

(9) How solid is the WG consensus behind this document? D= oes it=20 =20 represent the strong concurrence of a few individuals, with= others =20 being silent, or does the WG as a whole understand and agre= e with it?

(10) Has anyone threatened an appeal or otherwise indicat= ed extreme=20 =20 discontent? If so, please summarise the areas of conflict i= n separate =20 email messages to the Responsible Area Director. (It should= be in a =20 separate email because this questionnaire is publicly avail= able.)

(11) Identify any ID nits the Document Shepherd has found= in this =20 document. (See http://www.ietf.org/tools/idnits/ and the Internet-= Drafts =20 Checklist). Boilerplate checks are not enough; this check n= eeds to be =20 thorough.

(12) Describe how the document meets any required formal = review =20 criteria, such as the MIB Doctor, media type, and URI type = reviews.

(13) Have all references within this document been identi= fied as =20 either normative or informative?

(14) Are there normative references to documents that are= not ready for =20 advancement or are otherwise in an unclear state? If such n= ormative =20 references exist, what is the plan for their completion?

(15) Are there downward normative references references (= see RFC 3967)? =20 If so, list these downward references to support the Area D= irector in the =20 Last Call procedure.

(16) Will publication of this document change the status = of any =20 existing RFCs? Are those RFCs listed on the title page head= er, listed =20 in the abstract, and discussed in the introduction? If the = RFCs are not =20 listed in the Abstract and Introduction, explain why, and p= oint to the =20 part of the document where the relationship of this documen= t to the =20 other RFCs is discussed. If this information is not in the = document, =20 explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the I= ANA considerations =20 section, especially with regard to its consistency with the= body of the =20 document. Confirm that all protocol extensions that the doc= ument makes =20 are associated with the appropriate reservations in IANA re= gistries. =20 Confirm that any referenced IANA registries have been clear= ly =20 identified. Confirm that newly created IANA registries incl= ude a =20 detailed specification of the initial contents for the regi= stry, that =20 allocations procedures for future registrations are defined= , and a =20 reasonable name for the new registry has been suggested (se= e RFC 5226).

(18) List any new IANA registries that require Expert Rev= iew for future =20 allocations. Provide any public guidance that the IESG woul= d find =20 useful in selecting the IANA Experts for these new registri= es.

(19) Describe reviews and automated checks performed by t= he Document =20 Shepherd to validate sections of the document written in a = formal =20 language, such as XML code, BNF rules, MIB definitions, etc= .


--f46d043c80e68dc1be04d976b293-- From jeanmichel.combes@gmail.com Wed Apr 3 08:56:54 2013 Return-Path: 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 C9AAA21F8F26; Wed, 3 Apr 2013 08:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 Ilc7ME+v1AKy; Wed, 3 Apr 2013 08:56:53 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4186321F8EF5; Wed, 3 Apr 2013 08:56:45 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k13so4391221wgh.5 for ; Wed, 03 Apr 2013 08:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZyItAdLWV7DnAXVusIZrno+PtAEv+yKZT4R8lLpoNro=; b=TFDsqnsxF55NFdZBiEztICOJd3ELBrQ9KsB/y8bpAZGkgq7VF/+b2HqTfozBoKUjld xBk5QiWQUiR1qSYAGHRzFgZFNE1zL0vzptVACzuNzFHG5Kkm8MzjAQIR+pOjm1UxMF+d eOvwubisQS8w04x5KFmsCAilNIp1SaykZS/Tj4f+iA5qmJ0mZWN95DFVdEZHxuz2nyGO Dyj3DpmL2u3BzSEExhuvlUZ/XgNzYR3G3V77c9yFFrqqmcdjjMQqmfja11uQc/pL0C1X C7H5MvYJYPlPbVOSZ5AxSzCr5xaYM1PUa7frmpIZ1KSwObG6yThOTr4GHOtyLDcDsXPM 2XAQ== MIME-Version: 1.0 X-Received: by 10.180.90.35 with SMTP id bt3mr5179503wib.4.1365004604350; Wed, 03 Apr 2013 08:56:44 -0700 (PDT) Received: by 10.194.234.66 with HTTP; Wed, 3 Apr 2013 08:56:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Apr 2013 17:56:44 +0200 Message-ID: From: Jean-Michel Combes To: iesg-secretary@ietf.org Content-Type: multipart/alternative; boundary=f46d043c80e68f27e704d976e697 Cc: int-ads@tools.ietf.org, SAVI Mailing List , "savi-chairs@tools.ietf.org" Subject: Re: [savi] Publication request for "SEND-based Source-Address Validation Implementation" (draft-ietf-savi-send-09) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 15:56:55 -0000 --f46d043c80e68f27e704d976e697 Content-Type: text/plain; charset=ISO-8859-1 With the missing part of the I-D write-up ... (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The Document Shepperd has no specific concerns or issues with this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure has been filed that references this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG consensus is strong behind this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) Nobody has threatened an appeal or otherwise indicated extreme discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The Document Shepherd didn't find any ID nits in this document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review is required. (13) Have all references within this document been identified as either normative or informative? All references within this document have been identified as either normative or informative. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? There are no normative references that are not ready for advancement or are otherwise in an unclear state. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. The publication of this document will not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). This document has no actions for IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. This document has no actions for IANA. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. This document doesn't include sections written in a formal language. Best regards, JMC. 2013/4/3 Jean-Michel Combes > Dear Secretary, > > This is a request to publish draft-ietf-savi-send-09 as Standard track > RFC. Please find below the I-D write-up. > > Thanks in advance. > > Best regards, > > JMC. > > > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is this the proper > type of RFC? Is this type of RFC indicated in the title page header? > > Proposed Standard is being requested. > > Based on RFC 2026 and RFC 6410, this is the proper type of RFC. > > This type of RFC is indicated in the title page header. > > > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved documents. > The approval announcement contains the following sections: > > Technical Summary: > > This memo describes SEND SAVI, a mechanism to provide source address > validation using the SEND protocol. The proposed mechanism is intended to > complement ingress filtering techniques to provide a finer granularity on > the control of the source addresses used. > > Working Group Summary: > > There is SAVI WG consensus behind the document. > > Document Quality: > > This document was thoroughly reviewed by Ana Kukec, Tony Cheneau, Greg > Daley and Jean-Michel Combes. > > Personnel: > > The Document Shepherd is Jean-Michel Combes (jeanmichel.combes at > gmail.com), as savi WG chair. > > The Responsible Area Director is Ted Lemon (ted.lemon at nominum.com) > > (3) Briefly describe the review of this document that was performed by > the Document Shepherd. If this version of the document is not ready for > publication, please explain why the document is being forwarded to the > IESG. > > During his review, the Document Shepherd focused on these main points: > > - Compliance with "Source Address Validation Improvement Framework" > document (draft-ietf-framework-06) > > - Compliance with issues raised during the IESG review for "FCFS SAVI: > First-Come, First-Served Source Address Validation Improvement for Locally > Assigned IPv6 Addresses" (RFC 6620) > > - Compliance with SEND specifications > > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? > > The document Shepherd have no concerns about the depth or breadth of the > reviews that have been performed. > > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that took > place. > > As the csi WG is closed now, the document Shepherd thinks there is no more > place to request a review from SEND experts. So, the document Shepherd > thinks this document doesn't need review from a particular or from broader > perspective. > > (6) Describe any specific concerns or issues that the Document Shepherd > has with this document that the Responsible Area Director and/or the IESG > should be aware of? For example, perhaps he or she is uncomfortable with > certain parts of the document, or has concerns whether there really is a > need for it. In any event, if the WG has discussed those issues and has > indicated that it still wishes to advance the document, detail those > concerns here. > > The > > (7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. If not, explain why? > > (8) Has an IPR disclosure been filed that references this document? If so, > summarize any WG discussion and conclusion regarding the IPR disclosures. > > (9) How solid is the WG consensus behind this document? Does it represent > the strong concurrence of a few individuals, with others being silent, or > does the WG as a whole understand and agree with it? > > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate email > messages to the Responsible Area Director. (It should be in a separate > email because this questionnaire is publicly available.) > > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. > > (12) Describe how the document meets any required formal review criteria, > such as the MIB Doctor, media type, and URI type reviews. > > (13) Have all references within this document been identified as either > normative or informative? > > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? > > (15) Are there downward normative references references (see RFC 3967)? If > so, list these downward references to support the Area Director in the Last > Call procedure. > > (16) Will publication of this document change the status of any existing > RFCs? Are those RFCs listed on the title page header, listed in the > abstract, and discussed in the introduction? If the RFCs are not listed in > the Abstract and Introduction, explain why, and point to the part of the > document where the relationship of this document to the other RFCs is > discussed. If this information is not in the document, explain why the WG > considers it unnecessary. > > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes are > associated with the appropriate reservations in IANA registries. Confirm > that any referenced IANA registries have been clearly identified. Confirm > that newly created IANA registries include a detailed specification of the > initial contents for the registry, that allocations procedures for future > registrations are defined, and a reasonable name for the new registry has > been suggested (see RFC 5226). > > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find useful in > selecting the IANA Experts for these new registries. > > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal language, > such as XML code, BNF rules, MIB definitions, etc. > > --f46d043c80e68f27e704d976e697 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
With the missing part of the I-D write-up ...

(= 6) Describe any specific concerns or issues that the Document Shepherd =20 has with this document that the Responsible Area Director a= nd/or the =20 IESG should be aware of? For example, perhaps he or she is = uncomfortable =20 with certain parts of the document, or has concerns whether= there really =20 is a need for it. In any event, if the WG has discussed tho= se issues and =20 has indicated that it still wishes to advance the document,= detail those =20 concerns here.

The Document Shepperd has no spec= ific concerns or issues with this document.

(7) Has each author confirmed that any and all appropriat= e IPR =20 disclosures required for full conformance with the provisio= ns of BCP 78 =20 and BCP 79 have already been filed. If not, explain why?

Each author confirmed that any and all appropriate IPR disclosures requ= ired for full conformance with the provisions of BCP 78 =20 and BCP 79 have already been filed.

(8) Has an IPR disclosure been filed that references this= document? =20 If so, summarize any WG discussion and conclusion regarding= the IPR =20 disclosures.

No IPR disclosure has been filed th= at references this document.

(9) How solid is the WG consensus behind this document? D= oes it=20 =20 represent the strong concurrence of a few individuals, with= others =20 being silent, or does the WG as a whole understand and agre= e with it?

The WG consensus is strong behind this document.
<= /p>

(10) Has anyone threatened an appeal or otherwise indicat= ed extreme=20 =20 discontent? If so, please summarise the areas of conflict i= n separate =20 email messages to the Responsible Area Director. (It should= be in a =20 separate email because this questionnaire is publicly avail= able.)

Nobody has threatened an appeal or otherwise indicated ex= treme discontent.

(11) Identify any ID nits the Document Shepherd has found= in this =20 document. (See http://www.ietf.org/tools/idnits/ and the Internet-= Drafts =20 Checklist). Boilerplate checks are not enough; this check n= eeds to be =20 thorough.

The Document Shepherd didn't find = any ID nits in this document.

(12) Describe how the document meets any required formal = review =20 criteria, such as the MIB Doctor, media type, and URI type = reviews.

No formal review is required.

(13) Have all references within this document been identi= fied as =20 either normative or informative?

All references = within this document have been identified as either normative or informativ= e.

(14) Are there normative references to documents that are= not ready for =20 advancement or are otherwise in an unclear state? If such n= ormative =20 references exist, what is the plan for their completion?

There are no normative references that are not ready for advanceme= nt or are otherwise in an unclear state.

(15) Are there downward normative references references (= see RFC 3967)? =20 If so, list these downward references to support the Area D= irector in the =20 Last Call procedure.

There are no downward norma= tive references.

(16) Will publication of this document change the status = of any =20 existing RFCs? Are those RFCs listed on the title page head= er, listed =20 in the abstract, and discussed in the introduction? If the = RFCs are not =20 listed in the Abstract and Introduction, explain why, and p= oint to the =20 part of the document where the relationship of this documen= t to the =20 other RFCs is discussed. If this information is not in the = document, =20 explain why the WG considers it unnecessary.

The= publication of this document will not change the status of any existing RF= Cs.

(17) Describe the Document Shepherd's review of the I= ANA considerations =20 section, especially with regard to its consistency with the= body of the =20 document. Confirm that all protocol extensions that the doc= ument makes =20 are associated with the appropriate reservations in IANA re= gistries. =20 Confirm that any referenced IANA registries have been clear= ly =20 identified. Confirm that newly created IANA registries incl= ude a =20 detailed specification of the initial contents for the regi= stry, that =20 allocations procedures for future registrations are defined= , and a =20 reasonable name for the new registry has been suggested (se= e RFC 5226).

This document has no actions for IANA.

(18) List any new IANA registries that require Expert Rev= iew for future =20 allocations. Provide any public guidance that the IESG woul= d find =20 useful in selecting the IANA Experts for these new registri= es.

This document has no actions for IANA.

(19) Describe reviews and automated checks performed by t= he Document =20 Shepherd to validate sections of the document written in a = formal =20 language, such as XML code, BNF rules, MIB definitions, etc= .

This document doesn't include sections written in a formal= language.


Best regards,

JMC.



2013/4/3 Jean-Michel Combes <= jeanmichel.combes@gmail.com>
Dear Secretary,

This= is a request to publish draft-ietf-savi-send-09 as Standard track RFC. Ple= ase find below the I-D write-up.

Thanks in advance.

Best regards,

JMC.


(1) What type of RFC is being requested (BCP, Proposed St= andard, =20 Internet Standard, Informational, Experimental, or Historic= )? Why =20 is this the proper type of RFC? Is this type of RFC indica= ted in the =20 title page header?

Proposed Standard is being re= quested.

Based on RFC 2026 and RFC 6410, this is the proper type of R= FC.

This type of RFC is indicated in the title page header.


(2) The IESG approval announcement includes a Document Annou= ncement =20 Write-Up. Please provide such a Document Announcement Write= -Up. Recent =20 examples can be found in the "Action" announcemen= ts for approved =20 documents. The approval announcement contains the following= sections:

Technical Summary:

This memo describes SEND SAVI, a mechanism to provide= source address validation using the SEND protocol. The proposed mechanism = is intended to complement ingress filtering techniques to provide a finer g= ranularity on the control of the source addresses used.

Working Group Summary:

There is SAVI WG consensus behind the document.

Document Quality:

This document was thoroughly reviewed by Ana Kukec, T= ony Cheneau, Greg Daley and Jean-Michel Combes.

Personnel:

The Document Shepherd is Jean-Michel Combes (jeanmichel.combe= s at gmail.com), as savi= WG chair.

The Responsible Area Director is Ted Lemon (ted.lemon at nominum.com)

(3) Briefly describe the review of this document that was= performed by =20 the Document Shepherd. If this version of the document is = not ready =20 for publication, please explain why the document is being f= orwarded to =20 the IESG.

During his review, the Document Shephe= rd focused on these main points:

- Compliance with "Source Addre= ss Validation Improvement Framework" document (draft-ietf-framework-06= )

- Compliance with issues raised during the IESG review for "FCFS SA= VI: First-Come, First-Served Source Address Validation Improvement for Loca= lly Assigned IPv6 Addresses" (RFC 6620)

- Compliance with SEND s= pecifications

(4) Does the document Shepherd have any concerns about the depth or =20 breadth of the reviews that have been performed?

The document Shepherd have no concerns about the depth or breadth of the r= eviews that have been performed.

(5) Do portions of the document need review from a partic= ular or from =20 broader perspective, e.g., security, operational complexity= , AAA, DNS, =20 DHCP, XML, or internationalization? If so, describe the rev= iew that =20 took place.

As the csi WG is closed now, the doc= ument Shepherd thinks there is no more place to request a review from SEND = experts. So, the document Shepherd thinks this document doesn't need re= view from a particular or from broader perspective.

(6) Describe any specific concerns or issues that the Doc= ument Shepherd =20 has with this document that the Responsible Area Director a= nd/or the =20 IESG should be aware of? For example, perhaps he or she is = uncomfortable =20 with certain parts of the document, or has concerns whether= there really =20 is a need for it. In any event, if the WG has discussed tho= se issues and =20 has indicated that it still wishes to advance the document,= detail those =20 concerns here.

The

(7) Has each author confirmed that any and all appropriat= e IPR =20 disclosures required for full conformance with the provisio= ns of BCP 78 =20 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this= document? =20 If so, summarize any WG discussion and conclusion regarding= the IPR =20 disclosures.

(9) How solid is the WG consensus behind this document? D= oes it=20 =20 represent the strong concurrence of a few individuals, with= others =20 being silent, or does the WG as a whole understand and agre= e with it?

(10) Has anyone threatened an appeal or otherwise indicat= ed extreme=20 =20 discontent? If so, please summarise the areas of conflict i= n separate =20 email messages to the Responsible Area Director. (It should= be in a =20 separate email because this questionnaire is publicly avail= able.)

(11) Identify any ID nits the Document Shepherd has found= in this =20 document. (See http://www.ietf.org/tools/idnits/ and the Internet-= Drafts =20 Checklist). Boilerplate checks are not enough; this check n= eeds to be =20 thorough.

(12) Describe how the document meets any required formal = review =20 criteria, such as the MIB Doctor, media type, and URI type = reviews.

(13) Have all references within this document been identi= fied as =20 either normative or informative?

(14) Are there normative references to documents that are= not ready for =20 advancement or are otherwise in an unclear state? If such n= ormative =20 references exist, what is the plan for their completion?

(15) Are there downward normative references references (= see RFC 3967)? =20 If so, list these downward references to support the Area D= irector in the =20 Last Call procedure.

(16) Will publication of this document change the status = of any =20 existing RFCs? Are those RFCs listed on the title page head= er, listed =20 in the abstract, and discussed in the introduction? If the = RFCs are not =20 listed in the Abstract and Introduction, explain why, and p= oint to the =20 part of the document where the relationship of this documen= t to the =20 other RFCs is discussed. If this information is not in the = document, =20 explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the I= ANA considerations =20 section, especially with regard to its consistency with the= body of the =20 document. Confirm that all protocol extensions that the doc= ument makes =20 are associated with the appropriate reservations in IANA re= gistries. =20 Confirm that any referenced IANA registries have been clear= ly =20 identified. Confirm that newly created IANA registries incl= ude a =20 detailed specification of the initial contents for the regi= stry, that =20 allocations procedures for future registrations are defined= , and a =20 reasonable name for the new registry has been suggested (se= e RFC 5226).

(18) List any new IANA registries that require Expert Rev= iew for future =20 allocations. Provide any public guidance that the IESG woul= d find =20 useful in selecting the IANA Experts for these new registri= es.

(19) Describe reviews and automated checks performed by t= he Document =20 Shepherd to validate sections of the document written in a = formal =20 language, such as XML code, BNF rules, MIB definitions, etc= .



--f46d043c80e68f27e704d976e697-- From jmh.direct@joelhalpern.com Wed Mar 27 09:46:16 2013 Return-Path: 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 73B4D21F8EB5; Wed, 27 Mar 2013 09:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 tcJqbV31EYYL; Wed, 27 Mar 2013 09:46:15 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6657821F8A0B; Wed, 27 Mar 2013 09:45:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 525DC1BDD6C2; Wed, 27 Mar 2013 09:45:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-233.clppva.east.verizon.net [70.106.135.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 827ED1BDD4BD; Wed, 27 Mar 2013 09:45:45 -0700 (PDT) Message-ID: <5153222E.30202@joelhalpern.com> Date: Wed, 27 Mar 2013 12:45:34 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Black, David" References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D23D4052ABE7A4490E77B1A012B63077511F644@mbx-01.win.nominum.com> <8D3D17ACE214DC429325B2B98F3AE71293D36520@MX15A.corp.emc.com> <51531EA4.4030504@joelhalpern.com> <8D3D17ACE214DC429325B2B98F3AE71293D366C6@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293D366C6@MX15A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 04 Apr 2013 08:17:04 -0700 Cc: "McPherson, Danny" , "savi@ietf.org" , "ietf@ietf.org" , "gen-art@ietf.org" , Jean-Michel Combes , Ted Lemon , "joel.halpern@ericsson.com" Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 16:46:16 -0000 Then it will be done. I will wait for the AD to decide what other changes are needed, and then will either make this change or include it in an RFC Editor note. Thank you, Joel On 3/27/2013 12:42 PM, Black, David wrote: > That would do nicely. > > Thanks, > --David > > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Wednesday, March 27, 2013 12:30 PM >> To: Black, David >> Cc: Ted Lemon; McPherson, Danny; savi@ietf.org; ietf@ietf.org; gen- >> art@ietf.org; Jean-Michel Combes; joel.halpern@ericsson.com >> Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06 >> >> Would it suffice to replace >> Old: >> If the bridging topologies which connects the switches changes, or >> if LACP [IEEE802.3ad] changes which links are used to deliver >> traffic, the switch may need to move the SAVI state to a different >> port, are the state may need to be moved or reestablished on a >> different switch. >> New: >> If the bridging topologies which connects the switches changes, or >> if LACP [IEEE802.3ad], VRRP, or other link management >> operations, change which links are used to deliver >> traffic, the switch may need to move the SAVI state to a different >> port, are the state may need to be moved or reestablished on a >> different switch. >> ? >> >> Proposed changes on the second - fourth lines above. >> Yours, >> Joel >> >> On 3/26/2013 7:45 PM, Black, David wrote: >>> Ted, >>> >>>> Remembering that this is an informational draft, which does a pretty good >> job >>>> of informing the reader about the problem space, is it your opinion that >> the >>>> issues you have raised _must_ be addressed before the document is >> published, >>>> or do you think the document is still valuable even if no further text is >>>> added to address your concern? >>> >>> At a minimum, in section 4.1.2, this should be addressed: >>> >>> b) the new text implies that LACP is the only way to cause this situation - >> it's >>> not, so LACP should be used as an example. >>> >>> I'm not sure I've seen Fred's response, but that change would suffice. An >> RFC >>> Editor note should suffice. >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: Ted Lemon [mailto:Ted.Lemon@nominum.com] >>>> Sent: Monday, March 25, 2013 9:38 PM >>>> To: Black, David >>>> Cc: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen- >> art@ietf.org; >>>> Jean-Michel Combes; savi@ietf.org; ietf@ietf.org >>>> Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06 >>>> >>>> On Mar 25, 2013, at 9:04 PM, "Black, David" wrote: >>>>> Summary: This draft is on the right track, but has open issues, described >> in >>>> the review. >>>> >>>> While I identified the same issue you did with switching systems that do >> link >>>> aggregation and other magic, I think that the document is useful whether >> this >>>> is fixed or not. It's true that it doesn't have a full section that talks >>>> specifically about this problem, but I think it's unlikely that the authors >>>> are going to add one-when I mentioned it to Joel, he didn't express >> excitement >>>> at the prospect. >>>> >>>> I think Fred's response, while a little salty, accurately represents the >>>> situation: the working group produced this document, the document does what >>>> it's supposed to do, one could continue to polish it indefinitely, but then >>>> the document would never get published. >>>> >>>> Remembering that this is an informational draft, which does a pretty good >> job >>>> of informing the reader about the problem space, is it your opinion that >> the >>>> issues you have raised _must_ be addressed before the document is >> published, >>>> or do you think the document is still valuable even if no further text is >>>> added to address your concern? >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> > From david.black@emc.com Wed Apr 3 10:04:42 2013 Return-Path: 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 716C221F8F56; Wed, 3 Apr 2013 10:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qPdFAoY03Sjy; Wed, 3 Apr 2013 10:04:40 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6899321F8F40; Wed, 3 Apr 2013 10:04:38 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r33H4Xe3026469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Apr 2013 13:04:33 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Wed, 3 Apr 2013 13:04:14 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r33H4ALW029953; Wed, 3 Apr 2013 13:04:10 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Wed, 3 Apr 2013 13:04:09 -0400 From: "Black, David" To: "Black, David" , "McPherson, Danny" , Fred Baker , "joel.halpern@ericsson.com" , "gen-art@ietf.org" Date: Wed, 3 Apr 2013 13:04:08 -0400 Thread-Topic: Gen-ART review of draft-ietf-savi-threat-scope-07 Thread-Index: AcwRKxLMGPOwf18pRUizv8st+VLKC4QxHuTAAbSUPlA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71293D371CF@MX15A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Thu, 04 Apr 2013 08:17:05 -0700 Cc: "ietf@ietf.org" , "Black, David" , "savi@ietf.org" , Ted Lemon , Jean-Michel Combes Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-07 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 17:04:42 -0000 The -07 version of this draft resolves all of the issues raised by the Gen-= ART review of the -06 version. Discussion of the review with the authors has resulted in a common understanding that there is no need for additional tex= t on statically allowing all source addresses through all links in a set of teamed/aggregated links - that's at best "nice to have" for this draft, but not essential. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, March 25, 2013 9:04 PM > To: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen-art@ietf= .org > Cc: Jean-Michel Combes; Ted Lemon; savi@ietf.org; Black, David; ietf@ietf= .org > Subject: Gen-ART review of draft-ietf-savi-threat-scope-06 >=20 > I have been selected as the General Area Review Team (Gen-ART) reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >=20 > Please wait for direction from your document shepherd or > AD before posting a new version of the draft. >=20 > Document: draft-ietf-savi-threat-scope-06 > Reviewer: David L. Black > Review Date: March 27, 2013 > IESG Telechat Date: (if known) >=20 > Summary: This draft is on the right track, but has open issues, described= in > the review. >=20 > Looking at the original Gen-ART review of the -05 draft and checking the = diffs > between -05 and -06, the issues raised by that review have only been part= ially > addressed: >=20 > > There is no discussion of link teaming or aggregation (e.g., via LACP);= this > > may affect source address validation functionality by requiring the sam= e > > validation checks on all aggregated ports. An important case to discus= s > > is where the aggregated host links are connected to ports on different > > switches (e.g., in an active/passive configuration). >=20 > This is partially addressed on 4.1.2 (new section in -06), but only in te= rms > of moving validation state when something like LACP reconfigures. This h= as a > couple of shortcomings: > a) the alternative of statically allowing all source addresses through a= ll > teamed/aggregated links (decouples SAVI state from link > teaming/aggregation > state) should also be mentioned, and > b) the new text implies that LACP is the only way to cause this situation= - > it's > not, so LACP should be used as an example. VRRP is another example. >=20 > > (1) Some of the software switch implementations are single instance swi= tches > > whose implementation is distributed across multiple physical servers. = This > > results in concerns similar to the link aggregation discussion above. >=20 > I don't think this has been addressed, but the notion of single-instance > switches > could be added to the generalization of the new text in 4.1.2. >=20 > > (2) Live migration of virtual machines among physical servers causes > > relocation of MAC addresses across switch ports. A so-called "gratuito= us > ARP" > > is often used to inform the network of the MAC address move; port-based > > source address validation information needs to move in response to such > ARPs. > > > > (3) MAC address relocation is also used as a failure recovery technique= ; the > > surviving hardware element (e.g., host in a cluster) takes over the MAC > > addresses of the failed hardware; like the previous case, a "gratuitous= ARP" > > is a common means of informing the network that the MAC address has mov= ed, > > and source address validation information needs to move in response to = it. > > > > Minor issues: > > > > There doesn't seem to be much discussion of dynamic network reconfigura= tion, > > which may change traffic egress points. VRRP may be a useful example t= o > > discuss beyond the typical routing protocol updates to forwarding table= s. >=20 > A paragraph has been added to 5.2.3 to address all three of the above > concerns. > I guess that's ok, but I would have liked to see some text pointing out t= hat a > MAC move can be detected by the switches and used to update SAVI state ab= out > which port(s) a MAC is accessed through. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Black, David > > Sent: Friday, May 13, 2011 1:03 AM > > To: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen- > art@ietf.org > > Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko; > > savi@ietf.org > > Subject: Gen-ART review of draft-ietf-savi-threat-scope-05 > > > > I am the assigned Gen-ART reviewer for this draft. For background on > > Gen-ART, please see the FAQ at > > . > > > > Please resolve these comments along with any other Last Call comments > > you may receive. > > > > Document: draft-ietf-savi-threat-scope-05 > > Reviewer: David L. Black > > Review Date: 12 May 2011 > > IETF LC End Date: 18 May 2011 > > > > Summary: This draft is on the right track, but has open issues, describ= ed in > > the review. > > > > This draft discusses the threats and deployment environment for IP sour= ce > > address validation with particular attention to finer-grain validation = that > > could be used within a network to validate IP addresses closer to the > sources > > of network traffic than ingress to an ISP's network. > > > > Major issues: > > > > There is no discussion of link teaming or aggregation (e.g., via LACP);= this > > may affect source address validation functionality by requiring the sam= e > > validation checks on all aggregated ports. An important case to discus= s > > is where the aggregated host links are connected to ports on different > > switches > > (e.g., in an active/passive configuration). > > > > The discussion of multi-instance hosts in section 5.2.3 is incomplete > > in several important aspects: > > > > (1) Some of the software switch implementations are single instance swi= tches > > whose implementation is distributed across multiple physical servers. = This > > results in concerns similar to the link aggregation discussion above. > > > > (2) Live migration of virtual machines among physical servers causes > > relocation of MAC addresses across switch ports. A so-called "gratuito= us > ARP" > > is often used to inform the network of the MAC address move; port-based > > source address validation information needs to move in response to such > ARPs. > > > > (3) MAC address relocation is also used as a failure recovery technique= ; the > > surviving hardware element (e.g., host in a cluster) takes over the MAC > > addresses of the failed hardware; like the previous case, a "gratuitous= ARP" > > is a common means of informing the network that the MAC address has mov= ed, > > and source address validation information needs to move in response to = it. > > > > Minor issues: > > > > There doesn't seem to be much discussion of dynamic network reconfigura= tion, > > which may change traffic egress points. VRRP may be a useful example t= o > > discuss beyond the typical routing protocol updates to forwarding table= s. > > > > Nits/editorial comments: > > > > idnits 2.12.11 ran clean. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293= -7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > From jmh@joelhalpern.com Tue Apr 9 08:40:50 2013 Return-Path: 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 0420721F972F; Tue, 9 Apr 2013 08:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 vLFfD1LVNQpL; Tue, 9 Apr 2013 08:40:48 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id DED8321F97C5; Tue, 9 Apr 2013 08:40:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C8FA11BDF568; Tue, 9 Apr 2013 08:40:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-50.clppva.east.verizon.net [70.106.135.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id BA5C61BDF51F; Tue, 9 Apr 2013 08:40:40 -0700 (PDT) Message-ID: <51643664.1000407@joelhalpern.com> Date: Tue, 09 Apr 2013 11:40:20 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-savi-threat-scope@tools.ietf.org, SAVI Mailing List , Ted Lemon , IESG Subject: [savi] proposed revisions to draft-ietf-savi-threat-scope X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:40:50 -0000 I have chatted with Stephen (thanks Stephen, the Skype call was VERY helpful) about his discuss points. I believe we have the agreements below. Ted, do you want me to make those now, or should I wait till after the Thursday call. ---------- First, I found the following old agreement which I missed, which will help: Existing sentence: SAVI is aimed at providing locally more specific protection, with the benefit of better local behavior and local traceability, while also providing better compliance with the cases dealt with by BCP 38. Proposed repair: SAVI is aimed at providing locally more specific protection, with the benefit of better local behavior and, in conjunction with appropriate logging, better local traceability, while also providing better compliance with the cases dealt with by BCP 38. Existing Sentence: This both that the information be useable (logging), and that the information be accurate, i.e. that no other machine could have been using that address. Proposed repair, with typo fix, and grammar repair: Thus both that the information be useable (appropriate logging), and that the information be accurate (SAVI), i.e. that no other machine could have been using that address, are useful to the enterprise operator. ---------- Second, I will add a paragraph after he first paragraph of section 8.1 saying roughly: Collection of binding logging information is helpful for detecting and understanding internal spoof events. For spoof prevention and analysis information, it is sufficient to keep binding logs for the lifetime of the bindings. Spoof event reports would clearly have longer significance. Deleting the logs in a timely fashion can help address user privacy issues. --------- For comment 1: Current: Source address validation is necessary in order to detect and reject spoofed packets at the IP layer in the network, Proposed replacement: Source address validation is necessary in order to detect and reject IP spoofed packets in the network, ------- The above are hoped to resolve comment 1. ------- For comment 3, in the definition of Spoofing, add "currently" before "properly claimed". ------- For comment 4, if we can be clear that SAVI is concerned with the IP source address checking in IP packets, and IP address claims and assignments in IP claiming or assignment messages, that would help address the concern. Suggested approach is to add a definition of this, and reference that in the introduction of section 4. --------- As agreed in the earlier email exchange, for comment 9, in section 6 change "then it is possible to respond" to read "this can help in responding". --------- For comment 11, add a second sentence after the first one in section 8.1 saying "In some circumstances this binding data may be considered personally identifying information." ------ Agreed to clear points 6 and 10 in the discuss. For completeness, noting here that I will add the expansion of "LAND" that Stephen found for me. From stephen.farrell@cs.tcd.ie Tue Apr 9 08:47:44 2013 Return-Path: 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 A796521F979A; Tue, 9 Apr 2013 08:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 m8zhqfvMMcVo; Tue, 9 Apr 2013 08:47:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A033A21F960D; Tue, 9 Apr 2013 08:47:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47895BE68; Tue, 9 Apr 2013 16:47:19 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F24Fa-6+Vx0k; Tue, 9 Apr 2013 16:47:19 +0100 (IST) Received: from [IPv6:2001:770:10:203:54d4:67d3:a46c:a5f2] (unknown [IPv6:2001:770:10:203:54d4:67d3:a46c:a5f2]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DD6D2BE58; Tue, 9 Apr 2013 16:47:09 +0100 (IST) Message-ID: <516437FD.1020309@cs.tcd.ie> Date: Tue, 09 Apr 2013 16:47:09 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Joel M. Halpern" References: <51643664.1000407@joelhalpern.com> In-Reply-To: <51643664.1000407@joelhalpern.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org, Ted Lemon , IESG Subject: Re: [savi] proposed revisions to draft-ietf-savi-threat-scope X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:47:44 -0000 Hi Joel, Those all look good to me and enough to get this cleared maybe with wordsmiting when we have a revised I-D. I think the only one that might need wordsmithing is the one about discuss point 4 ("address claiming messages") and I'm happy that you and I have the same idea on what to do for that. The others should all be good to go as per your text below. Thank you and all for your patience, Stephen. On 04/09/2013 04:40 PM, Joel M. Halpern wrote: > I have chatted with Stephen (thanks Stephen, the Skype call was VERY > helpful) about his discuss points. I believe we have the agreements below. > > Ted, do you want me to make those now, or should I wait till after the > Thursday call. > > ---------- > First, I found the following old agreement which I missed, which will help: > > Existing sentence: > SAVI is aimed at providing locally more specific protection, with the > benefit of better local behavior and local traceability, while also > providing better compliance with the cases dealt with by BCP 38. > > Proposed repair: > SAVI is aimed at providing locally more specific protection, with the > benefit of better local behavior and, in conjunction with appropriate > logging, better local traceability, while also providing better > compliance with the cases dealt with by BCP 38. > > Existing Sentence: > This both that the information be useable (logging), and that the > information be accurate, i.e. that no other machine could have been > using that address. > > Proposed repair, with typo fix, and grammar repair: > Thus both that the information be useable (appropriate logging), and > that the information be accurate (SAVI), i.e. that no other machine > could have been using that address, are useful to the enterprise operator. > ---------- > > Second, I will add a paragraph after he first paragraph of section 8.1 > saying roughly: > > Collection of binding logging information is helpful for detecting and > understanding internal spoof events. For spoof prevention and analysis > information, it is sufficient to keep binding logs for the lifetime of > the bindings. Spoof event reports would clearly have longer > significance. Deleting the logs in a timely fashion can help address > user privacy issues. > > --------- > > For comment 1: > Current: > Source address validation is necessary in order to detect and reject > spoofed packets at the IP layer in the network, > > Proposed replacement: > Source address validation is necessary in order to detect and reject IP > spoofed packets in the network, > > ------- > The above are hoped to resolve comment 1. > ------- > > For comment 3, in the definition of Spoofing, add "currently" before > "properly claimed". > > ------- > > For comment 4, if we can be clear that SAVI is concerned with the IP > source address checking in IP packets, and IP address claims and > assignments in IP claiming or assignment messages, that would help > address the concern. > Suggested approach is to add a definition of this, and reference that in > the introduction of section 4. > > --------- > > As agreed in the earlier email exchange, for comment 9, in section 6 > change "then it is possible to respond" to read "this can help in > responding". > > --------- > > For comment 11, add a second sentence after the first one in section 8.1 > saying "In some circumstances this binding data may be considered > personally identifying information." > > ------ > > Agreed to clear points 6 and 10 in the discuss. > > For completeness, noting here that I will add the expansion of "LAND" > that Stephen found for me. > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From Ted.Lemon@nominum.com Tue Apr 9 09:37:36 2013 Return-Path: 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 2140D21F9022; Tue, 9 Apr 2013 09:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 mHkHmrWWB8g9; Tue, 9 Apr 2013 09:37:30 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 18D5221F8F16; Tue, 9 Apr 2013 09:37:30 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUWRDyW4jjD0ziWvQWUXcoEyBRaL9PFMa@postini.com; Tue, 09 Apr 2013 09:37:30 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8285B1B8385; Tue, 9 Apr 2013 09:37:29 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7C1E1190061; Tue, 9 Apr 2013 09:37:29 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 09:37:29 -0700 From: Ted Lemon To: "Joel M. Halpern" Thread-Topic: proposed revisions to draft-ietf-savi-threat-scope Thread-Index: AQHONTiayJiVnvGP8E2gztiuDaYHUJjOi/MA Date: Tue, 9 Apr 2013 16:37:29 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513AC03@mbx-01.win.nominum.com> References: <51643664.1000407@joelhalpern.com> In-Reply-To: <51643664.1000407@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , SAVI Mailing List , IESG , Stephen Farrell Subject: Re: [savi] proposed revisions to draft-ietf-savi-threat-scope X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:37:36 -0000 On Apr 9, 2013, at 11:40 AM, "Joel M. Halpern" wrote: > Ted, do you want me to make those now, or should I wait till after the Th= ursday call. I would like to see a revision of the document prior to the call. Given that the SAVI working group has been Cc'd on this whole exchange, I w= onder, informally, if anyone in that working group has any feelings about t= hese changes that they would like to share with us prior to the telechat. = My assumption is that these changes have all been editorial improvements t= hat do not change the core meaning of the document. From junbi@cernet.edu.cn Tue Apr 9 09:57:24 2013 Return-Path: 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 2DD1A21F8B1E; Tue, 9 Apr 2013 09:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2vwB6pD428GY; Tue, 9 Apr 2013 09:57:23 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id C59C521F8265; Tue, 9 Apr 2013 09:57:22 -0700 (PDT) Received: from junbithinkpadx1 (unknown [59.66.24.163]) by centos (Coremail) with SMTP id AQAAf3DLAQf9R2RR0aIYAA--.13898S5; Wed, 10 Apr 2013 00:55:28 +0800 (CST) From: "Jun Bi" To: "'Ted Lemon'" , "'Joel M. Halpern'" References: <51643664.1000407@joelhalpern.com> <8D23D4052ABE7A4490E77B1A012B63077513AC03@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077513AC03@mbx-01.win.nominum.com> Date: Wed, 10 Apr 2013 00:56:58 +0800 Message-ID: <001401ce3543$3fff4ce0$bffde6a0$@cernet.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJQ/vQ8QEek9sp4+/m51UcVFa91/wJB/GQYl7Z4V5A= Content-Language: zh-cn X-CM-TRANSID: AQAAf3DLAQf9R2RR0aIYAA--.13898S5 X-Coremail-Antispam: 1UD129KBjvdXoW7JF4fKw1UKF1kKry7Kw47CFg_yoWkWrX_uF Wjqwn7G34jyF4Ut3WUJrn8twnxXr47uFy7A3yDJrnI9ry0yFs5JFsrKrWfZr13GFW7Xr1a 9Fn3Jw1xtFW3XjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbekYjsxI4VWDJwAYFVCjjxCrM7AC8VAFwI0_Gr0_Xr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwA2z4x0Y4vEx4A2jsIE14v26r1j6r4UM28EF7xvwVC2z280aVCY1x0267AKxVW8JVW8Jr 1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0Ex4A2 jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACjcxG0x vY0x0EwIxGrVCF72vEw4AK0wCY02Avz4vE14v_JwCF04k20xvY0x0EwIxGrwC20s026c02 F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw 1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI 0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU IuyIUUUUU X-CM-SenderInfo: xmxquxg6fh20lhwovvfxof0/ Cc: 'SAVI Mailing List' , draft-ietf-savi-threat-scope@tools.ietf.org, 'IESG' , 'Stephen Farrell' Subject: Re: [savi] proposed revisions to draft-ietf-savi-threat-scope X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:57:24 -0000 Yes, a revision before the call is better. Thanks, Jun -----Original Message----- From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, April 10, 2013 12:37 AM To: Joel M. Halpern Cc: ; SAVI Mailing List; IESG; Stephen Farrell Subject: Re: [savi] proposed revisions to draft-ietf-savi-threat-scope On Apr 9, 2013, at 11:40 AM, "Joel M. Halpern" wrote: > Ted, do you want me to make those now, or should I wait till after the Thursday call. I would like to see a revision of the document prior to the call. Given that the SAVI working group has been Cc'd on this whole exchange, I wonder, informally, if anyone in that working group has any feelings about these changes that they would like to share with us prior to the telechat. My assumption is that these changes have all been editorial improvements that do not change the core meaning of the document. _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From jmh@joelhalpern.com Tue Apr 9 11:22:31 2013 Return-Path: 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 CF42821F928D for ; Tue, 9 Apr 2013 11:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 GQFn9TwFxv8t for ; Tue, 9 Apr 2013 11:22:21 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id AA33521F8FD4 for ; Tue, 9 Apr 2013 11:22:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 7685E1228F5; Tue, 9 Apr 2013 11:22:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-50.clppva.east.verizon.net [70.106.135.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CCC501228F3; Tue, 9 Apr 2013 11:22:15 -0700 (PDT) Message-ID: <51645C43.5070602@joelhalpern.com> Date: Tue, 09 Apr 2013 14:21:55 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Stephen Farrell , SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [savi] Proposed additional privacy paragraph X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 18:22:31 -0000 Trying to wordsmith what Stephen and I talked about, I ended up with: For this reason, the collection and retention of logged binding information needs to be considered carefully. Prevention of spoofing does not in itself require such retention. Analysis of immediate events may rely on having logs of current bindings. Thus, privacy issues can be ameliorated by removing binding logs after the binding lifetimes expire. Logs of apparent spoof attempts are a separate matter, and may require longer retention to detect patterns of deliberate or accidental abuse. Yours, Joel From housley@vigilsec.com Tue Apr 9 15:36:25 2013 Return-Path: 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 E63C421F90BB; Tue, 9 Apr 2013 15:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 eExCO2rGBBNc; Tue, 9 Apr 2013 15:36:24 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id B1E8421F9051; Tue, 9 Apr 2013 15:36:24 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B50D89A4112; Tue, 9 Apr 2013 18:36:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id KKu1GypQBele; Tue, 9 Apr 2013 18:36:20 -0400 (EDT) Received: from [192.168.2.100] (pool-173-79-232-68.washdc.fios.verizon.net [173.79.232.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CC52F9A410F; Tue, 9 Apr 2013 18:36:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71293D371CF@MX15A.corp.emc.com> Date: Tue, 9 Apr 2013 18:36:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <34B1BF5C-9A14-4B86-BA51-9780F2832ACF@vigilsec.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293D371CF@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1085) Cc: IETF Gen-ART , savi@ietf.org, IETF Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-07 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 22:36:26 -0000 David: Thanks for your efforts on this document. Your first review was in May = 2011, and the document has improved greatly for you continued pushing on = the concerns. Russ On Apr 3, 2013, at 1:04 PM, Black, David wrote: > The -07 version of this draft resolves all of the issues raised by the = Gen-ART > review of the -06 version. Discussion of the review with the authors = has > resulted in a common understanding that there is no need for = additional text > on statically allowing all source addresses through all links in a set = of > teamed/aggregated links - that's at best "nice to have" for this = draft, but > not essential. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Black, David >> Sent: Monday, March 25, 2013 9:04 PM >> To: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; = gen-art@ietf.org >> Cc: Jean-Michel Combes; Ted Lemon; savi@ietf.org; Black, David; = ietf@ietf.org >> Subject: Gen-ART review of draft-ietf-savi-threat-scope-06 >>=20 >> I have been selected as the General Area Review Team (Gen-ART) = reviewer >> for this draft (for background on Gen-ART, please see >> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >>=20 >> Please wait for direction from your document shepherd or >> AD before posting a new version of the draft. >>=20 >> Document: draft-ietf-savi-threat-scope-06 >> Reviewer: David L. Black >> Review Date: March 27, 2013 >> IESG Telechat Date: (if known) >>=20 >> Summary: This draft is on the right track, but has open issues, = described in >> the review. >>=20 >> Looking at the original Gen-ART review of the -05 draft and checking = the diffs >> between -05 and -06, the issues raised by that review have only been = partially >> addressed: >>=20 >>> There is no discussion of link teaming or aggregation (e.g., via = LACP); this >>> may affect source address validation functionality by requiring the = same >>> validation checks on all aggregated ports. An important case to = discuss >>> is where the aggregated host links are connected to ports on = different >>> switches (e.g., in an active/passive configuration). >>=20 >> This is partially addressed on 4.1.2 (new section in -06), but only = in terms >> of moving validation state when something like LACP reconfigures. = This has a >> couple of shortcomings: >> a) the alternative of statically allowing all source addresses = through all >> teamed/aggregated links (decouples SAVI state from link >> teaming/aggregation >> state) should also be mentioned, and >> b) the new text implies that LACP is the only way to cause this = situation - >> it's >> not, so LACP should be used as an example. VRRP is another = example. >>=20 >>> (1) Some of the software switch implementations are single instance = switches >>> whose implementation is distributed across multiple physical = servers. This >>> results in concerns similar to the link aggregation discussion = above. >>=20 >> I don't think this has been addressed, but the notion of = single-instance >> switches >> could be added to the generalization of the new text in 4.1.2. >>=20 >>> (2) Live migration of virtual machines among physical servers causes >>> relocation of MAC addresses across switch ports. A so-called = "gratuitous >> ARP" >>> is often used to inform the network of the MAC address move; = port-based >>> source address validation information needs to move in response to = such >> ARPs. >>>=20 >>> (3) MAC address relocation is also used as a failure recovery = technique; the >>> surviving hardware element (e.g., host in a cluster) takes over the = MAC >>> addresses of the failed hardware; like the previous case, a = "gratuitous ARP" >>> is a common means of informing the network that the MAC address has = moved, >>> and source address validation information needs to move in response = to it. >>>=20 >>> Minor issues: >>>=20 >>> There doesn't seem to be much discussion of dynamic network = reconfiguration, >>> which may change traffic egress points. VRRP may be a useful = example to >>> discuss beyond the typical routing protocol updates to forwarding = tables. >>=20 >> A paragraph has been added to 5.2.3 to address all three of the above >> concerns. >> I guess that's ok, but I would have liked to see some text pointing = out that a >> MAC move can be detected by the switches and used to update SAVI = state about >> which port(s) a MAC is accessed through. >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: Black, David >>> Sent: Friday, May 13, 2011 1:03 AM >>> To: McPherson, Danny; Fred Baker; joel.halpern@ericsson.com; gen- >> art@ietf.org >>> Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko; >>> savi@ietf.org >>> Subject: Gen-ART review of draft-ietf-savi-threat-scope-05 >>>=20 >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> . >>>=20 >>> Please resolve these comments along with any other Last Call = comments >>> you may receive. >>>=20 >>> Document: draft-ietf-savi-threat-scope-05 >>> Reviewer: David L. Black >>> Review Date: 12 May 2011 >>> IETF LC End Date: 18 May 2011 >>>=20 >>> Summary: This draft is on the right track, but has open issues, = described in >>> the review. >>>=20 >>> This draft discusses the threats and deployment environment for IP = source >>> address validation with particular attention to finer-grain = validation that >>> could be used within a network to validate IP addresses closer to = the >> sources >>> of network traffic than ingress to an ISP's network. >>>=20 >>> Major issues: >>>=20 >>> There is no discussion of link teaming or aggregation (e.g., via = LACP); this >>> may affect source address validation functionality by requiring the = same >>> validation checks on all aggregated ports. An important case to = discuss >>> is where the aggregated host links are connected to ports on = different >>> switches >>> (e.g., in an active/passive configuration). >>>=20 >>> The discussion of multi-instance hosts in section 5.2.3 is = incomplete >>> in several important aspects: >>>=20 >>> (1) Some of the software switch implementations are single instance = switches >>> whose implementation is distributed across multiple physical = servers. This >>> results in concerns similar to the link aggregation discussion = above. >>>=20 >>> (2) Live migration of virtual machines among physical servers causes >>> relocation of MAC addresses across switch ports. A so-called = "gratuitous >> ARP" >>> is often used to inform the network of the MAC address move; = port-based >>> source address validation information needs to move in response to = such >> ARPs. >>>=20 >>> (3) MAC address relocation is also used as a failure recovery = technique; the >>> surviving hardware element (e.g., host in a cluster) takes over the = MAC >>> addresses of the failed hardware; like the previous case, a = "gratuitous ARP" >>> is a common means of informing the network that the MAC address has = moved, >>> and source address validation information needs to move in response = to it. >>>=20 >>> Minor issues: >>>=20 >>> There doesn't seem to be much discussion of dynamic network = reconfiguration, >>> which may change traffic egress points. VRRP may be a useful = example to >>> discuss beyond the typical routing protocol updates to forwarding = tables. >>>=20 >>> Nits/editorial comments: >>>=20 >>> idnits 2.12.11 ran clean. >>>=20 >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Distinguished Engineer >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> david.black@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>>=20 >=20 From Ted.Lemon@nominum.com Tue Apr 9 17:30:02 2013 Return-Path: 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 C65A521F98CE; Tue, 9 Apr 2013 17:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 kmy5Pn66JXMQ; Tue, 9 Apr 2013 17:30:02 -0700 (PDT) Received: from exprod7og129.obsmtp.com (exprod7og129.obsmtp.com [64.18.2.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1592521F98A4; Tue, 9 Apr 2013 17:30:01 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob129.postini.com ([64.18.6.12]) with SMTP ID DSNKUWSyiQyJGuHL2v8H7olDkAUw+VBzTHxz@postini.com; Tue, 09 Apr 2013 17:30:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7423B1B87B0; Tue, 9 Apr 2013 17:30:01 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6B970190061; Tue, 9 Apr 2013 17:30:01 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 17:30:01 -0700 From: Ted Lemon To: Russ Housley Thread-Topic: Gen-ART review of draft-ietf-savi-threat-scope-07 Thread-Index: AQHOMI1VsmvJehwUjES862bjgyecEJjO+YyAgAAfwwA= Date: Wed, 10 Apr 2013 00:30:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513B7E4@mbx-01.win.nominum.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293AEEDC8@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71293D371CF@MX15A.corp.emc.com> <34B1BF5C-9A14-4B86-BA51-9780F2832ACF@vigilsec.com> In-Reply-To: <34B1BF5C-9A14-4B86-BA51-9780F2832ACF@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Black, David" , "" , IETF Gen-ART , IETF Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-07 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 00:30:02 -0000 On Apr 9, 2013, at 6:36 PM, Russ Housley wrote: > Thanks for your efforts on this document. Your first review was in May 2= 011, and the document has improved greatly for you continued pushing on the= concerns. Can we take this to mean that the concerns expressed in your now-deprecated= DISCUSS have been successfully addressed? From internet-drafts@ietf.org Tue Apr 9 17:36:13 2013 Return-Path: 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 6DD9521F992E; Tue, 9 Apr 2013 17:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 tltKaizM0vzm; Tue, 9 Apr 2013 17:36:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 640EC21F9928; Tue, 9 Apr 2013 17:35:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130410003550.32635.9560.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 17:35:50 -0700 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-threat-scope-08.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 00:36:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvements Wo= rking Group of the IETF. Title : SAVI Threat Scope Author(s) : Danny McPherson Fred Baker Joel M. Halpern Filename : draft-ietf-savi-threat-scope-08.txt Pages : 25 Date : 2013-04-09 Abstract: Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-threat-scope-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-savi-threat-scope-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmh@joelhalpern.com Tue Apr 9 17:42:38 2013 Return-Path: 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 09ED621F9915; Tue, 9 Apr 2013 17:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Pr1xwO1lS60p; Tue, 9 Apr 2013 17:42:36 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id DC33E21F98EA; Tue, 9 Apr 2013 17:42:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id CA242141AE9; Tue, 9 Apr 2013 17:42:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-50.clppva.east.verizon.net [70.106.135.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E7EE8141AE8; Tue, 9 Apr 2013 17:42:35 -0700 (PDT) Message-ID: <5164B567.7030209@joelhalpern.com> Date: Tue, 09 Apr 2013 20:42:15 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ted Lemon References: <20130410003550.32635.9560.idtracker@ietfa.amsl.com> In-Reply-To: <20130410003550.32635.9560.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130410003550.32635.9560.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-savi-threat-scope@tools.ietf.org, SAVI Mailing List , IESG Subject: [savi] Fwd: I-D Action: draft-ietf-savi-threat-scope-08.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 00:42:38 -0000 As requested by Ted, I have submitted a revision of the document. I believe this resolves all outstanding discuss items, and most of the comments. (Barry, thanks for the check on some really bad sentences.) Yours, Joel -------- Original Message -------- Subject: I-D Action: draft-ietf-savi-threat-scope-08.txt Date: Tue, 09 Apr 2013 17:35:50 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: savi@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SAVI Threat Scope Author(s) : Danny McPherson Fred Baker Joel M. Halpern Filename : draft-ietf-savi-threat-scope-08.txt Pages : 25 Date : 2013-04-09 Abstract: Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-threat-scope-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-threat-scope-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From iesg-secretary@ietf.org Mon Apr 15 13:42:36 2013 Return-Path: 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 45B4021F8263; Mon, 15 Apr 2013 13:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 ZMYNSyQe+Scx; Mon, 15 Apr 2013 13:42:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DFB21F941D; Mon, 15 Apr 2013 13:42:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130415204234.9178.14661.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 13:42:34 -0700 Cc: savi mailing list , savi chair , RFC Editor Subject: [savi] Document Action: 'SAVI Threat Scope' to Informational RFC (draft-ietf-savi-threat-scope-08.txt) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 20:42:36 -0000 The IESG has approved the following document: - 'SAVI Threat Scope' (draft-ietf-savi-threat-scope-08.txt) as Informational RFC This document is the product of the Source Address Validation Improvements Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope/ Technical Summary This document describes the threats that SAVI could address. Working Group Summary The working group process went normally. Document Quality There are existing implementations of various SAVI-like features in the current equipment. Personnel The responsible Area Director is Ted Lemon. From iesg-secretary@ietf.org Mon Apr 15 13:42:36 2013 Return-Path: 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 865FC21F8443 for ; Mon, 15 Apr 2013 13:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 SBmP-2VRlggC; Mon, 15 Apr 2013 13:42:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3281E21F9409; Mon, 15 Apr 2013 13:42:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-savi-threat-scope X-IETF-Draft-revision: 08 Message-ID: <20130415204235.9178.52182.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 13:42:35 -0700 Cc: savi mailing list , savi chair , RFC Editor Subject: [savi] Document Action: 'SAVI Threat Scope' to Informational RFC (draft-ietf-savi-threat-scope-08.txt) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 20:42:36 -0000 The IESG has approved the following document: - 'SAVI Threat Scope' (draft-ietf-savi-threat-scope-08.txt) as Informational RFC This document is the product of the Source Address Validation Improvements Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope/ Technical Summary This document describes the threats that SAVI could address. Working Group Summary The working group process went normally. Document Quality There are existing implementations of various SAVI-like features in the current equipment. Personnel The responsible Area Director is Ted Lemon. From internet-drafts@ietf.org Fri Apr 26 07:11:46 2013 Return-Path: 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 443D121F999C; Fri, 26 Apr 2013 07:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 VTxu9rvFPxpv; Fri, 26 Apr 2013 07:11:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D09F321F9968; Fri, 26 Apr 2013 07:11:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426141145.27970.23694.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 07:11:45 -0700 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-send-10.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2013 14:11:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvements Wo= rking Group of the IETF. Title : SEND-based Source-Address Validation Implementation Author(s) : Marcelo Bagnulo Alberto Garcia-Martinez Filename : draft-ietf-savi-send-10.txt Pages : 35 Date : 2013-04-26 Abstract: This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-send There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-send-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-savi-send-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hammondjohnson@hushmail.com Sat Apr 27 15:49:05 2013 Return-Path: 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 E0F8521F99C0 for ; Sat, 27 Apr 2013 15:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 5or40ZT37qTd for ; Sat, 27 Apr 2013 15:49:05 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2E521F99BF for ; Sat, 27 Apr 2013 15:49:05 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id D6C90E7AD4 for ; Sat, 27 Apr 2013 18:02:02 +0000 (UTC) X-hush-relay-time: 220 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 18:02:02 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 17AA7E6736; Sat, 27 Apr 2013 18:02:02 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 14:02:01 -0400 To: savi@ietf.org From: hammondjohnson@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427180202.17AA7E6736@smtp.hushmail.com> Subject: [savi] Biggest Fake Conference in Computer Science X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 22:49:06 -0000 We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From internet-drafts@ietf.org Tue Apr 30 01:13:32 2013 Return-Path: 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 7554E21F9BF7; Tue, 30 Apr 2013 01:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.442 X-Spam-Level: X-Spam-Status: No, score=-99.442 tagged_above=-999 required=5 tests=[AWL=-3.125, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_XBL=3.033, 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 8+yTvHVaakrS; Tue, 30 Apr 2013 01:13:25 -0700 (PDT) Received: from jlonline.com (pip46.ptt.js.cn [61.155.13.222]) by ietfa.amsl.com (Postfix) with SMTP id 1D22221F9BA3; Tue, 30 Apr 2013 01:13:22 -0700 (PDT) Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm2a517f8c61; Tue, 30 Apr 2013 16:19:10 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm21517aa211; Fri, 26 Apr 2013 22:17:56 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Fri, 26 Apr 2013 22:17:56 +0800 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 904EA21F99A0; Fri, 26 Apr 2013 07:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1366985509; bh=De/Gaa0kI7G6WKHmHBgIH7Vcf9n483duB1MWXZahxy4=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=dB/AdvqSASzRoUP9XT0sCnjiegtrfjwJhf5PSxt4MPCAbzUy26jxpbOXy/IcXCm8q YwtYBGRYvfetTSN8uCaT9v4IRRSRJ5IU7LgJCtWbpHHSz+283XZTOXIgZvepcCJcDs c4jIihjFSEIyHnhpk3DsBVsoxJ+FCgwATVl8/ZtE= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443D121F999C; Fri, 26 Apr 2013 07:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 VTxu9rvFPxpv; Fri, 26 Apr 2013 07:11:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D09F321F9968; Fri, 26 Apr 2013 07:11:45 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130426141145.27970.23694.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 07:11:45 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: jlS3j54B X-AIMC-AUTH: (null) X-AIMC-MAILFROM: internet-drafts@ietf.org Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-send-10.txt X-BeenThere: savi@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 08:13:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SEND-based Source-Address Validation Implementation Author(s) : Marcelo Bagnulo Alberto Garcia-Martinez Filename : draft-ietf-savi-send-10.txt Pages : 35 Date : 2013-04-26 Abstract: This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-send There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-send-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-send-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt