All of lore.kernel.org
 help / color / mirror / Atom feed
From: arno@natisbad.org (Arnaud Ebalard)
To: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: netdev@vger.kernel.org
Subject: [PATCH net-next-2.6 0/5] XFRM,IPv6: Removal of RH2/HAO from IPsec-protected MIPv6 traffic
Date: Fri, 24 Sep 2010 21:18:09 +0200	[thread overview]
Message-ID: <87bp7nrlvy.fsf@small.ssi.corp> (raw)

Hi,

First off, patches for discussion are in following emails. They are
*against current linux-2.6* (on which they were tested) but will be
rebased against net-next-2.6 for next round.

Simply put, the patches provides the ability to remove annoying Routing
Header Type 2 and Destination Options Header with Home Address Option
from IPsec-protected MIPv6 signaling traffic, changing on-wire format
from:


    MN  ------------ IPv6() / HAO / ESP(BU) ----------> HA
    MN  <----------- IPv6() / RH2 / ESP(BA) ----------- HA

to 

    MN  ------------ IPv6() / ESP(BU) --------------> HA
    MN  <----------- IPv6() / ESP(BA) --------------- HA


This is an *self-contained* part of a set of additional enhancements for
Mobile IPv6 when used w/ IPsec and IKE specified in IRO draft [1]. Once 
available, this can also be extended to IPsec-protected route optimized
communications between MN and CN/MN.

Among the operational benefits of the feature is the ability to run in
networks in which (dumb) firewalls drop Routing Headers (Cisco PIX
firewalls are known to do that by default and w/o ways of correcting the
issue). Anonimity is another.

Basically, RH2/HAO are only *explicit* containers for the Home Address
(HoA), which is obviously available in the IPsec stack (transport mode
SA protecting traffic use the HoA). This means that the info is
available on both sides and there is no real need to carry it explictly.

>From an implementation standpoint, some changes are required to allow
finding the SA when the addresses are not expected ones and remap them
if asked to do so (or act as usual if not). Then, most of the other
changes are basically simple versions of what can be found at the moment
for RH2 and HAO in DestOpt handling. Unlike what happens with RH2/HAO,
packets structure is never modified.

I rely on the feature on my MN (my laptop) and HA for 2 kernel versions
to provide me with connectivity (v4 networks are handled using
m6t [1]). Patches for UMIP [2] are available and will be merged upstream
if the feature gets accepted. At the moment, the people using the Debian
package for UMIP [3] can simply benefit from the feature by compiling a 
patched kernel (2.6.34 and 2.6.35.5 available [5]), and then doing a
simple apt-get remove umip && apt-get install umip-iro. 

Cheers,

a+

[1] http://tools.ietf.org/html/draft-ebalard-mext-ipsec-ro  
[2] http://natisbad.org/m6t/
[3] http://umip.org/
[4] http://umip.org/docs/umip-debrepo.html
[5] http://natisbad.org/IRO/

             reply	other threads:[~2010-09-24 19:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-24 19:18 Arnaud Ebalard [this message]
2010-09-24 19:21 ` [PATCH net-next-2.6 1/5] XFRM,IPv6: Remove xfrm_spi_hash() dependency on destination address Arnaud Ebalard
2010-09-24 19:22 ` [PATCH net-next-2.6 2/5] XFRM,IPv6: Introduce receive sockopts to access IRO remapped src/dst addresses Arnaud Ebalard
2010-09-24 19:24 ` [PATCH net-next-2.6 3/5] XFRM,IPv6: Add IRO src/dst address remapping XFRM types and i/o handlers Arnaud Ebalard
2010-09-24 19:25 ` [PATCH net-next-2.6 4/5] XFRM,IPv6: Add IRO remapping hook in xfrm_input() Arnaud Ebalard
2010-09-24 19:26 ` [PATCH net-next-2.6 5/5] XFRM,IPv6: Add IRO remapping capability via socket ancillary data path Arnaud Ebalard
2010-09-28  4:25 ` [PATCH net-next-2.6 0/5] XFRM,IPv6: Removal of RH2/HAO from IPsec-protected MIPv6 traffic David Miller
2010-09-28 15:53   ` Arnaud Ebalard
     [not found] <87ocbnxa0i.fsf@small.ssi.corp>
2010-09-24 19:01 ` David Miller
2010-09-24 19:34   ` 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=87bp7nrlvy.fsf@small.ssi.corp \
    --to=arno@natisbad.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.