Re: [Softwires] Ambiguity in MAP-E receiving rules

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Mon, 05 August 2013 20:00 UTC

Return-Path: <rajiva@cisco.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5E121F9425 for <softwires@ietfa.amsl.com>; Mon, 5 Aug 2013 13:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.499
X-Spam-Level:
X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 5vfQQCi7mtyV for <softwires@ietfa.amsl.com>; Mon, 5 Aug 2013 13:00:32 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 86AAC21F9703 for <softwires@ietf.org>; Mon, 5 Aug 2013 13:00:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2782; q=dns/txt; s=iport; t=1375732828; x=1376942428; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Oq1w9og+KcJQohmiSM5zMaunK6+7em/oBy+jmCZ3mnE=; b=QoyRs5Ify5P7A9VbEjrcI/FU7M7wYaON5wVAuSingE59xGKH0O0cGX1L k+Q4R8ZINTP1dnKOt9qolwtTzjMUuCUSPLYYwMgtTKISoucRi1CzrxprP x/3penP+vz4Wnd8pyyNl2kDoVxu1juJZEAHILk1S3S57Y+b1L6Vu+si/j E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAJYDAFKtJV2a/2dsb2JhbABbgwY1UL51gSEWdIIkAQEBBAEBATc0CwwGAQgOAwMBAgsUMQYLHQgCBAENBQiHdgMPDKxDDYhaBI0ngkExBwaDE3QDlAmBbo4RhSeDF4FqJBw
X-IronPort-AV: E=Sophos;i="4.89,820,1367971200"; d="scan'208";a="243709149"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 05 Aug 2013 20:00:28 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r75K0RoB024590 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 20:00:27 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.225]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 15:00:27 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Ole Troan <otroan@employees.org>, Tom Taylor <tom.taylor.stds@gmail.com>
Thread-Topic: [Softwires] Ambiguity in MAP-E receiving rules
Thread-Index: AQHOkcT5TPeMmw3iMUWs1kv06FM8gZmHGggA
Date: Mon, 05 Aug 2013 20:00:27 +0000
Message-ID: <B14A62A57AB87D45BB6DD7D9D2B78F0B2A9F52E5@xmb-rcd-x06.cisco.com>
In-Reply-To: <BBE367A8-F797-4412-B88C-AF1255A62C10@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [10.82.222.46]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BB11B37621432B458B92A8E5D0CDA167@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2013 20:00:37 -0000

The updated text looks reasonable to me.

-----Original Message-----
From: Ole Troan <otroan@employees.org>
Date: Monday, August 5, 2013 6:16 AM
To: Tom Taylor <tom.taylor.stds@gmail.com>
Cc: Softwires-wg list <softwires@ietf.org>
Subject: Re: [Softwires] Ambiguity in MAP-E receiving rules

>>> 
>> [PTT] Is there any point to having the CPE generate logs? Who would
>>look at them -- the operator or the customer? If logging is useful on
>>the CPE, that should be reflected in our logging drafts, but if not, not.
>> 
>>> [ian] It may be useful to have the option of sending an ICMP error
>>>message
>>> for troubleshooting. What about if we have a 'should' requirement for
>>> logging the error on the CPE and a 'may' for sending an ICMP error
>>>message?
>
>RFC5969 has the following text:
>   In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE
>   MUST validate the embedded IPv4 source address of the encapsulated
>   IPv6 packet with the IPv4 source address it is encapsulated by
>   according to the configured parameters of the 6rd domain.  If the two
>   source addresses do not match, the packet MUST be dropped and a
>   counter incremented to indicate that a potential spoofing attack may
>   be underway.
>
>section 8.1 already say MUST drop for packets to an IPv4 address not
>belonging to it.
>I suggest we add that for ports too:
>
>old text:
>
>   In order to prevent spoofing of IPv4 addresses, the MAP node MUST
>   validate the embedded IPv4 source address of the encapsulated IPv6
>   packet with the IPv4 source address it is encapsulated by according
>   to the parameters of the matching mapping rule.  If the two source
>   addresses do not match, the packet MUST be dropped and a counter
>   incremented to indicate that a potential spoofing attack may be
>   underway.  Additionally, a CE MUST allow forwarding of packets
>   sourced by the configured BR IPv6 address.
>
>new text:
>
>   In order to prevent spoofing of IPv4 addresses, the MAP node MUST
>   validate the embedded IPv4 source address and transport layer port of
>the encapsulated IPv6
>   packet with the IPv4 source address and transport layer port it is
>encapsulated by according
>   to the parameters of the matching mapping rule.  If the two source
>   addresses and transport layer ports do not match, the packet MUST be
>silently discard and a counter
>   incremented to indicate that a potential spoofing attack may be
>   underway.  Additionally, a CE MUST allow forwarding of packets
>   sourced by the configured BR IPv6 address.
>
>
>
>cheers,
>Ole
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires