From: arno@natisbad•org (Arnaud Ebalard)
To: Herbert Xu <herbert@gondor•apana.org.au>
Cc: "David S. Miller" <davem@davemloft•net>,
Eric Dumazet <eric.dumazet@gmail•com>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6•org>,
netdev@vger•kernel.org
Subject: Re: [PATCHv4 net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook in xfrm_input()
Date: Mon, 04 Oct 2010 22:51:46 +0200 [thread overview]
Message-ID: <87vd5h7kbh.fsf@small.ssi.corp> (raw)
In-Reply-To: 20101004084041.GB17939@gondor.apana.org.au
Hi,
Herbert Xu <herbert@gondor•apana.org.au> writes:
> On Mon, Oct 04, 2010 at 08:25:23AM +0200, Arnaud Ebalard wrote:
>> Add a hook in xfrm_input() to allow IRO remapping to occur when
>> an incoming packet matching an existing SA (based on SPI) with
>> an unexpected destination or source address is received.
>> Because IRO does not consume additional bits in a packet (that's
>> the point), there is no way to demultiplex based on something
>> like nh or spi. Instead, IRO input handlers (for source and
>> destination address remapping) are called upon address mismatch
>> during IPsec processing.
>> For that to work, we rely on the fact that SPI values generated
>> locally are no more linked to destination address (first patch
>> of the set) and we postpone a bit the expected address check in
>> xfrm_input() (inside xfrm_state_lookup() against daddr param) by
>> introducing a call to the input_addr_check() handler from the
>> struct xfrm_state_afinfo associated with the address family.
>>
>> Signed-off-by: Arnaud Ebalard <arno@natisbad•org>
>
> I would prefer for this check to go into x->type->input since
> it does not apply to IPsec.
Either I don't understand the sentence or this is not feasible: the
thing is there is nothing in the packet to demultiplex like nh for
RH2/HAO. Here, we only lookup for a remapping state when there is a
mismatch in the source/destination addresses expected for the SA.
That's the reason IRO remapping states only apply to IPsec traffic.
> Just because the SPI is unique for inbound SAs, it doesn't mean
> that we should ignore the destination IP address in the packet for
> IPsec.
I don't ignore it. Before the change, for input IPsec traffic, the SA
lookup is done as follows:
- SA lookup based mostly on SPI
- Destination address check (done simultaneously during lookup)
fatal if mismatch
After the change, there are three steps for IPv6:
- SA lookup based on SPI
- Destination Address check
mismatch => lookup for destination remapping state
call for associated input handler
fatal if mismatch
- Source Address check
mismatch => lookup for source remapping state
call for associated input handler
Explanation makes it looks more complex than it is:
- IPv4 IPsec is basically untouched
- IPv6 IPsec is basically untouched when CONFIG_XFRM_SUB_POLICY is not
enabled,
- when CONFIG_XFRM_SUB_POLICY is enabled additional work is done only
for IPv6 upon address mismatch.
> I think another way of getting what you want is to simply add
> inbound SAs with a zero destination address in your case which
> can then be made to match any destination IP address. You can
> then follow that up with additional checks in x->type->input.
The idea is to allow the optimization for unmodified IPsec SA
(between stable addresses, i.e. HoA). Updating IRO src/dst remapping
states allow changing the src/dst on-wire address for unmodifed SA w/o
the need to explicitly add RH2 and/or HAO. Additionally, because source
and destination remapping are not linked, your proposal would not solve
the source remapping case, would it?
Thanks for your feedback and patience, Herbert!
Cheers,
a+
next prev parent reply other threads:[~2010-10-04 20:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 6:24 [PATCHv4 net-next-2.6 0/5] Removal of RH2/HAO from IPsec-protected MIPv6 traffic Arnaud Ebalard
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 1/5] XFRM,IPv6: Remove xfrm_spi_hash() dependency on destination address Arnaud Ebalard
2010-10-04 8:33 ` Herbert Xu
2010-10-04 20:51 ` Arnaud Ebalard
2010-10-05 2:11 ` Herbert Xu
2010-10-05 4:17 ` Herbert Xu
2010-10-07 20:13 ` Arnaud Ebalard
2010-10-08 0:42 ` Herbert Xu
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 2/5] XFRM,IPv6: Introduce receive sockopts to access IRO remapped src/dst addresses Arnaud Ebalard
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 3/5] XFRM,IPv6: Add IRO src/dst address remapping XFRM types and i/o handlers Arnaud Ebalard
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook in xfrm_input() Arnaud Ebalard
2010-10-04 8:40 ` Herbert Xu
2010-10-04 20:51 ` Arnaud Ebalard [this message]
2010-10-05 6:27 ` Herbert Xu
2010-10-05 23:28 ` Arnaud Ebalard
2010-10-06 1:25 ` Herbert Xu
2010-10-06 21:42 ` Arnaud Ebalard
2010-10-04 6:25 ` [PATCHv4 net-next-2.6 5/5] XFRM,IPv6: Add IRO remapping capability via socket ancillary data path Arnaud Ebalard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vd5h7kbh.fsf@small.ssi.corp \
--to=arno@natisbad$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=eric.dumazet@gmail$(echo .)com \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=netdev@vger$(echo .)kernel.org \
--cc=yoshfuji@linux-ipv6$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox