Re: [RAM] ETRs checking src & dest addresses
Iljitsch van Beijnum <iljitsch@muada.com> Thu, 12 July 2007 21:14 UTC
Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95zJ-0007Fi-0I; Thu, 12 Jul 2007 17:14:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95zI-0007Fd-CQ for ram@iab.org; Thu, 12 Jul 2007 17:14:12 -0400
Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I95zD-0006UO-WA for ram@iab.org; Thu, 12 Jul 2007 17:14:12 -0400
Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l6CLAtsv000814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Jul 2007 23:10:56 +0200 (CEST) (envelope-from iljitsch@muada.com)
In-Reply-To: <469615D5.4010408@firstpr.com.au>
References: <469615D5.4010408@firstpr.com.au>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <2EA94A78-B056-4938-B6E0-051EE4013A98@muada.com>
Content-Transfer-Encoding: 7bit
From: Iljitsch van Beijnum <iljitsch@muada.com>
Subject: Re: [RAM] ETRs checking src & dest addresses
Date: Thu, 12 Jul 2007 23:12:39 +0200
To: Robin Whittle <rw@firstpr.com.au>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org
On 12-jul-2007, at 13:51, Robin Whittle wrote: > In the current definition of Ivip, the SA of the outer packet is > the same as of the inner packet - it is the address of the > original sending host, not of the ITR. Maybe there is a reason > for using the ITR's address for the outer SA, but for now I will > assume not. What do security associations have to do with any of this? Oh wait, you mean source address. I don't think it's a good idea to have node Y send packets where the source address is X, both because this claims that the sender is different from his/her actual identity and because return traffic, such as ICMP messages, will then end up at (arguably) the wrong node. Knowing the address of the encapsulating TR is also useful if the decapsulating TR ever wants to get in touch with it. [not replying to the rest of the message because I didn't have time to read it] _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- [RAM] ETRs checking src & dest addresses Robin Whittle
- Re: [RAM] ETRs checking src & dest addresses Iljitsch van Beijnum
- Re: [RAM] ETRs checking src & dest addresses Robin Whittle