Subject: [Hipsec] AC/ACR or NES based RR?

From: [email-masked] (Pekka Nikander)
Date: Sun Mar 7 17:39:01 2004

Folks,

At the WG meeting in Seoul there was no clear
consensus on whether people prefer the explicit
AC/ACR based RR mechanism that was present in
the -00 version of the mobility and multi-homing
draft or the current NES based mechanism used
in the -01 draft.  Basically, only three people
showed hands, clearly indicating that more
clarification is needed on the issue.

The purpose of this message is to create some
discussion this issue so that more people could
form their opinions.  Even though this note is
intended to contain the essence of the difference,
reading the drafts is probably needed to really
understand the difference between the approaches.

The -00 draft is available at
http://www.watersprings.org/pub/id/draft-nikander-hip-mm-00.txt

The -01 draft is available at
http://www.ietf.org/internet-drafts/draft-nikander-hip-mm-01.txt,
and an early version of the to-be -02 is available at
http://www.tml.hut.fi/~pnr/HIP/

1. The AC/ACR approach

In the -00 draft, a REA was performed by an explicit
three way handshake, consisting of REA, AC, and ACR packets:

  A                               B
     REA: My new IP is 1.2.3.4
    --------------------------->
     AC: Are you at 1.2.3.4?
    <---------------------------
     ACR: Yes, I am
    --------------------------->

A major problem with the -00 draft was that it didn't
really address multi-homing requirements.  In particular,
the possibility of using multiple parallel SAs to
overcome difficulties with different path characteristics
and replay protection was missing.  However, other than
that the AC/ACR mechanism might still be useful.

Basically, to make the AC/ACR mechanism useful even in
the case where the sender of REA is multi-homed and
needs multiple parallel SAs, the AC needs to be made
more REA (or NES) like.  That is, if the REA introduces
a new B->A SA, the AC must introduce a corresponding
A->B SA.  The difference with the REA is that while the
REA introduces a new SA that has a new destination IP
address, the AC introduces a new SA that shares the
same destination IP address as the old one.

These parallel SAs are needed in both directions, since
the QoS mostly seems to depend on the path taken, not
the destination address.  Hence, when A sends packets
to B, it needs to decide on SA use based on the source
interface used, not the destination IP address.  The
two SAs are needed to make sure that no packets are
dropped at B due to different replay protection windows
on the different paths.

2.  The REA/NES approach

In the -01 draft, the REA packet was replaced with
a REA parameter, and both REA and NES parameters
were carried in UPDATE packets.

A                                                  B
     REA: My new IP is 1.2.3.4, NES: with SPI 1234
    ---------------------------------------------->
     NES: my new SPI corresponding is 4321
    <----------------------------------------------
     ESP traffic to B on SPI 4321
    ---------------------------------------------->

There were a number of motivating factors for this
change.  The ultimate factors were the desire to reuse
existing mechanism and architectural simplicity.

- reuse of the NES mechanism, with the hope of
   generating less code

- getting rid of ACR, as it is basically a binary
   message indicating that A received AC

- desire not to carry SPIs in REA as they need to
   be carried in the NES anyway

- better support for middle boxes by requiring
   them to track NES only, learning the SPIs from
   NES payloads, not elsewhere.

With regard to multi-homing, the -01 draft still
does not work quite right.  Basically, it does
not tell how to create SPIs in both direction.
Hence, some changes/additions are needed in order
to support bi-directional parallel SAs.

3. Remarks / thoughts

Considering a case like using GPRS (900 ms delay,
real throughput of maybe 10 kilobits/second) and
WLAN (20 ms delay, 5 Mb/s), it is clear that
different SAs are needed in both directions.
Otherwise any packet sent over the GPRS channel
will get dropped at the receiving end as outside
of the replay protection window.

In the A->B direction (A being multi-homed and
B not), there is no real different between the
parallel SAs.  A can use either of them on either
path.  Basically, it is A's responsibility to use
them in a sensible way so that replay protection
windows are never exceeded.  Hence, here we seem
to have the possibility where we have two address
groups (since we have two SAs), and a single
address shared between the address groups.

Hence, the REA/NES based transaction seems to
become in the multi-homing case like the following:

A                                                  B
     REA: My new IP is 1.2.3.4, NES: with SPI 1234
    ---------------------------------------------->
     REA: New address group     NES: with SPI 4321
    <----------------------------------------------
     ESP traffic to B on SPI 4321
    ---------------------------------------------->

Note that the second REA does *not* require any
RR test as it does not introduce any new addresses.

A remark about data structures:
- RR status is per address, not per address group
   or per address in an address group.  I.e. it is
   enough to check an address for RR once, and use
   that RR status even if the address appears later
   in new address groups.

Opinions/further thoughts/mistakes in my logic?

--Pekka

---

From: [email-masked] (Jari Arkko)
Date: Sun Mar 7 22:14:00 2004

Hi Pekka,

I'm not really responding to your specific question,
just commenting a few other related items... sorry
if this has been discussed before, I have recently
been too busy to follow all HIP discussions.

> of the replay protection window.

True. But there's also a corresponding transport
layer issue, even if you get the SAs right. If you
were carrying a single TCP session, the disparity
in the interface speeds would cause problems for TCP.
Hence it may make more sense to constrain the use
of multiple interfaces for failover rather than
load balancing, or even randomly using more than
one interface. Has this been discussed previously?
Are we talking about this yet anywhere in the
documents?

>     REA: My new IP is 1.2.3.4, NES: with SPI 1234

I'm just wondering how the REA - NES approach fits
in with possible RR optimizations that people have
talked about in MIPv6 and MOBOPTS groups. Perhaps
its too early to adopt any specific optimization to
HIP as people are just basically brainstorming about
it. But it might be good to think about it.

--Jari

---

From: [email-masked] (Pekka Nikander)
Date: Mon Mar 8 01:28:01 2004

Jari,

> layer issue, even if you get the SAs right.

Right.  This has been discussed a little bit, but we
certainly need more discussion on this.

> If you were carrying a single TCP session, the disparity
> one interface.

I think we have here two separate issues.  One is the
architectural issue wrt. transport use, which you mention.
There I fully agree with you that we do not want to do
anything, yet, at the working group side, but just say
that for a single TCP connection you just use a single
SPI at time, and you have to be pretty careful if you
switch it.  However, I do see there a great place for
some interesting work in the research group side.

The second issue is getting the HIP protocol right.
There I really think that we should specify it to have
multiple parallel SAs, even if the upper layer in a
given implementation were use only one of them at a time.
Getting this (almost) right doesn't seem to be that
complicated.  Basically, we need to have an SA pair for
each path.  We just have to make the signalling protocol
so that we have a reasonable abstraction for paths,
for associating paths with IP addresses, and for changing
the associated IP address set.

In the current drafts there is the deficit that they do
not really deal with SA pairs but try to come along with
unidirectional SAs.  That doesn't quite work, Jan Melen
noted while trying to implement this stuff.  (Again, we
see what value implementation has.)

As a conclusion, the "interface" concept which is used
in -01 is bad terminology.  Just renaming it to "address
group" as is done in -02-pre is not quite right, either.
We must represent paths, and associate them with IP
address pairs, not single addresses.   Apparently we have
to think a little bit more about this, independent on
whether we go back to AC/ACR or continue using SPIs as
RR triggers.

> Are we talking about this yet anywhere in the

I don't think so.

> it. But it might be good to think about it.

This is a very good question.  I really encourage
people to think about this, especially while evaluating
whether to use AC/ACR (-00 approach) or SPI triggers
(-01 approach).

--Pekka

---

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Mon Mar 8 07:12:01 2004

See the multi6 archives, especially the thread from October/November
on "Re: Notes on draft-crocker-mast-analysis-01.txt", and anything
posted by Mark Allman.

Spencer

From: "Jari Arkko" <[email-masked]>

---

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Mon Mar 8 07:35:01 2004

I may not be clear enough when I'm describing this... just a couple
more words, to see if I can be clearer.

Spencer

From: "Pekka Nikander" <[email-masked]>

> switch it.  However, I do see there a great place for

"Switching" paths for a single TCP connection is not a problem,
especially if you are switching paths for a reason (like, the old path
seems to have quit working).

The worst that can happen is that your new path gets some segments to
the far end more than four segments "out of order" from the old path,
and you generate a round of TCP fast retransmit/fast recovery, and we
have to accept that sometimes we'll choose a new path that's more
congested than the old path, so we would generate a round of TCP fast
retransmit/fast recovery anyway as we figure out what the new path
capacity is.

If you choose paths for a single TCP connection more often than TCP
can recovery from out of order delivery - think loadbalancing, with
round-robin selection as the limiting case - this IS a problem. TCP
slows down more quickly than it speeds up (additive increase,
multiplicative decrease), and you don't have to cut your estimate of
path bandwidth in half very often to be pretty noticeable.

For better or worse, we haven't widely deployed per-destination or
per-destination-subnet congestion management, so you can probably
choose a different path for different TCP connections to the same
destination, no problem, and can certainly choose a different path for
TCP connections to different destinations in the same subnet, no
problem.

Spencer