Subject: [Mobike] issue 11 -- window size

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 Apr 2005 13:57:55 +0300

Jari Arkko writes:
> 
> This issue is about the window size. Mobike needs to be able to
> send multiple messages, given that a regular IKEv2 exchange
> may be in progress when we suddenly change our IP address.
> The question is whether we should expect IKEv2 implementations
> to support window size greater than 1, or if Mobike's own
> exchanges are in some sense outside the regular IKEv2
> window (as proposed in Pasi's MOPO protocol).
> 
> The background information we got in the meeting was that
> in the IKEv2 bakeoff many implementors did not have
> support for larger than 1 window sizes.
> 
> So we could either require a larger window size or do MOBIKE
> exchanges outside the window. I did not sense a conclusion
> in the meeting about this, but on the other hand I'm not sure
> if people care about this issue very deeply. For the purpose
> of making progress, let me propose one approach. If the
> decision was "do it outside the window", would people have
> problems with that?

There is also one other option, i.e. the way my original protocol
proposal did it, i.e. every IKE packet can be used to test the paths.
If you add also so that every IKE packet also includes the information
needed to do mobility that solves the problem with window size 1.

I.e. if mobike needs n payload for its processing, you add those n
payloads to all IKE packets, and then when you are retransmitting the
IKE packet you simply also use that packet to do path finding, i.e.
change the source and destination addresses but keep the packet same.
The responder will reply to reversed addresses, and after that IKE
exchange both ends know that the path has changed, and can take
appropriate actions (either automatically or manually by sending
another exchange).

That protocol will work with window size of 1, and it does not need
any packets that are outside of the normal window processing. If we
still do manual actions, then we actually do not need any special
payloads in the IKE packets.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Apr 2005 15:51:02 +0300

Hi Tero,

This is interesting, I think it looks attractive!

(So what exactly would "information needed to
do mobility and path testing" constitute? Presumably, one of
the things that we would probably need is a NAT-D payload.
Would this mean that if we have send request X and later
realize that we don't get a response and have to retransmit
on another, new interface, we resubmit X exactly as-is?
Or can we add "mobility data", such as NAT-D payload?
Or perhaps "mobility data" is simply the source address
and NAT-D payloads are always included...?)

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Apr 2005 10:58:29 +0300

Jari Arkko writes:
> do mobility and path testing" constitute?

Depends about the answers to issue 3...

> Presumably, one of the things that we would probably need is a NAT-D
> payload.

Not necessarely, in the simplies form it would be simply outer IP
addresses and ports.

> on another, new interface, we resubmit X exactly as-is?

Yes. The packet must be resubmitted as-is, only IP-addresses and ports
can change. There responder might be taking HASH of the packet when
processing it and store the reply packet, and when he sees the
retransmission he must be able to match the hash of the previous
retransmission to this new one. 

> Or can we add "mobility data", such as NAT-D payload?

No, we cannot add those. 

> and NAT-D payloads are always included...?)

That would be one option.

I.e. in the simpliest way to get the protocol working would be
something like this:

Host A has 3 IP-addresses A1, A2, A3
Host B has 2 IP-addresses B1, B2

IKE SA is currently using (A1, B1)

Host A starts CREATE_CHILD_SA (message ID 55), and sends packet to B.

(A1, B1, 55) CREATE_CHILD_SA -> (dropped)

		There is something wrong with the path A1,B1 and
		packet is dropped (B1 does not work...)

Host A retransmits few times:

(A1, B1, 55) CREATE_CHILD_SA -> (dropped)
(A1, B1, 55) CREATE_CHILD_SA -> (dropped)
(A1, B1, 55) CREATE_CHILD_SA -> (dropped)

Host A notices he is not getting packets back, he starts searching for
the working address pair:

(A2, B1, 55) CREATE_CHILD_SA -> (dropped)
(A2, B1, 55) CREATE_CHILD_SA -> (dropped)
(A3, B1, 55) CREATE_CHILD_SA -> (dropped)
(A3, B1, 55) CREATE_CHILD_SA -> (dropped)
(A1, B2, 55) CREATE_CHILD_SA -> Host B gets the packet..

		Host B will immediately notice that there is something
		wrong with the path as the Host A is using different
		ports, but he simply continues processing the packet
		normally, and replies (with message id 55R) to the
		reversed addresses

		<- (B2, A1, 55R) CREATE_CHILD_SA reply

Host A gets the packet and notices that he has found a working path.
He decides that the he should move the traffic to that new address
pair too, so he sends address update packet to host B:

(A1, B2, 56) N(UPDATE ADDRESSES) ->

		Host B updates his SAs to new address pair, and
		replies.

		<- (B2, A1, 56R) N(UPDATE ADDRESS reply)

Now if we want to see why we cannot modify the packet between
retranmissions take the next case where we have also shorter temporary
failures or one way connections.

Connection between A1 and B2 breaks down (A1 address does not work).
Host A notices that he hasn't received anything and starts DPD.

(A1, B2, 57) DPD -> (dropped)
(A1, B2, 57) DPD -> (dropped)
(A1, B2, 57) DPD -> (dropped)

Host A notices that he is not getting anything back so he starts
searching for the working address pair:

(A2, B1, 57) DPD ->

		Host B gets the packet, and replies to it, but the
		packet is dropped because of some other reason (one
		way path etc). Host B has now calculated HASH(DPD) and
		stored it in his incoming window for message id 57,
		and also has stored the "DPD reply" to be sent back in
		case the message id 57 (HASH(DPD)) is retranmitted.

	(drop)	<- (B1, A2, 57R) DPD reply

Host A retransmits

(A2, B1, 57) DPD ->

		Host B gets retramission of 57, he verifies that it is
		retranmission by checking the HASH(DPD), and because
		it matches, he sends stored copy of message id 57R
		back, without doing any more processing for the
		packet (i.e. he does not run any IKE state machines to
		process the packet). 

	(drop)	<- (B1, A2, 57R) DPD reply

Host A moves to next address and retransmits

(A3, B1, 57) DPD ->

		Host B again notices about retranmission, and replies
		with his stored packet.

		<- (B1, A3, 57R) DPD reply

Now host A gets the packet, and he notices that the previously working
path (A1, B2) does not work anymore, but path (A3, B1) works, so he
updates the SAs to that new address pair

(A3, B1, 58) N(UPDATE ADDRESSES) ->

		Host B process this new notify, and replies

		<- (B1, A3, 58R) N(UPDATE ADDRESSES reply)

Host A and Host B again has working SAs.

So any packets between A and B needs to be processed identically, i.e.
all of them are finding the working address pair. After we have found
out the working address pair, we start the actual movement request
with the specific exchange N(UPDATE ADDRESS). Of course also the
N(UPDATE ADDRESS) packets gets the same processing, i.e. if the
packets do not get through we start searching for the working address
pair.

Depending on the protocol and contents of N(UPDATE ADDRESS) we need to
decide what we do if the address pair changes during the N(UPDATE
ADDRESS) exchange. I.e. if the addresses are also stored inside the
N(UPDATE ADDRESSES) then we can see that the addresses of outer header
and inside notify does not match, so either there is NAT or the
initiator needed to start address pair search after construction the
packet. In that case B can either reject the update (NAT prevention)
or simply accept it.

If host A needed to start address pair search, and he didn't like the
result he can start searching new address pair and when he has found
the one he likes, he can redo the N(UPDATE ADDRESS). 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 5 Apr 2005 17:41:14 -0700

Tero,

Some questions/clarifications..

> back, without doing any more processing for the
The receiver needs to do a HASH to detect the change.
Today the receiver on receiving the above message, just
 sends the stored response out as he knows it is a retransmission
 by just looking at the Message-id. 
 
> Host B again notices about retranmission, and replies
When the host detects the HASH change, he notes down
*just* the new addresses so that the response can be
sent to the new place. This implies that the retransmitted
request from the other end cannot have any changes in the payload
(except the IP header). If any other change is in the payload, 
then the stored response won't work.  This might be a bit
restrictive depending on how the protocol evolves. So, the main
advantage and difference of moving the PATH_TEST message
outside the normal window processing is that it can be a totally
new message. Hence NAT-D need not be included in every
message i guess. Perhaps, there might be something else in the
future. Even if we move the PATH_TEST message outside
the normal window, we might still have to potentially retransmit
the pending message with new address (as described here)
and hence the new processing from the receiver is still required.

-mohan

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Wed, 6 Apr 2005 09:02:56 -0400

Hi Tero,

> 
> There is also one other option, i.e. the way my original 
> protocol proposal did it, i.e. every IKE packet can be used 
> to test the paths.
> If you add also so that every IKE packet also includes the 
> information needed to do mobility that solves the problem 
> with window size 1.
> 
> I.e. if mobike needs n payload for its processing, you add 
> those n payloads to all IKE packets, and then when you are 
> retransmitting the IKE packet you simply also use that packet 
> to do path finding, i.e.
> The responder will reply to reversed addresses, and after 
> that IKE exchange both ends know that the path has changed, 
> and can take appropriate actions (either automatically or 
> manually by sending another exchange).

So, if you have two peers

PeerA(A1,A2) PeerB(B1,B2) which are using A1<->B1 for the initial
connection.

Given the following sequence of events
- Window Size = 1

A1 --> B1 (CREATE_CHILD_SA request)
Interface A1 goes down
A1 x-- B1 (CREATE_CHILD_SA response)

How would PeerA inform PeerB to start using A2?  It is unable to send any
IKE pkts at all without exceeding the window size.  Or are you relying on
PeerB to retransmit the response to A1 a few times, and then automatically
switch to A2?

Stephane.

> 
> That protocol will work with window size of 1, and it does 
> not need any packets that are outside of the normal window 
> processing. If we still do manual actions, then we actually 
> do not need any special payloads in the IKE packets.
> --
> [email-masked]

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Wed, 6 Apr 2005 10:25:48 -0400

Sorry, I didn't notice your other post until I sent this.  Your follow up
post answers my questions.

> information 
> PeerA(A1,A2) PeerB(B1,B2) which are using A1<->B1 for the 
> initial connection.
> 
> How would PeerA inform PeerB to start using A2?  It is unable 
> to send any IKE pkts at all without exceeding the window 
> size.  Or are you relying on PeerB to retransmit the response 
> to A1 a few times, and then automatically switch to A2?
> 
> Stephane.
> 
> >

---

From: "Stephane Beaulieu" <[email-masked]>
Date: Wed, 6 Apr 2005 10:31:13 -0400

Given the limitation of window sizes, I think this proposal is the best
we've discussed so far.

Unless someone can find something technically wrong with Tero's proposal, I
vote that we proceed with this approach.

Stephane. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tero Kivinen
> Sent: Tuesday, April 05, 2005 3:58 AM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: [Mobike] issue 11 -- window size
> 
> Jari Arkko writes:
> > (So what exactly would "information needed to do mobility and path 
> > testing" constitute?
> 
> Not necessarely, in the simplies form it would be simply 
> outer IP addresses and ports.
> 
> realize that 
> > we don't get a response and have to retransmit on another, new 
> > interface, we resubmit X exactly as-is?
> 
> Yes. The packet must be resubmitted as-is, only IP-addresses 
> and ports can change. There responder might be taking HASH of 
> the packet when processing it and store the reply packet, and 
> when he sees the retransmission he must be able to match the 
> hash of the previous retransmission to this new one. 
> 
> > Or perhaps "mobility data" is simply the source address and NAT-D 
> > payloads are always included...?)
> 
> I.e. in the simpliest way to get the protocol working would 
> be something like this:
> 
> (A1, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B1, 55) 
> CREATE_CHILD_SA -> (dropped) (A1, B1, 55) CREATE_CHILD_SA -> (dropped)
> 
> Host A notices he is not getting packets back, he starts 
> (A2, B1, 55) CREATE_CHILD_SA -> (dropped) (A2, B1, 55) 
> CREATE_CHILD_SA -> (dropped) (A3, B1, 55) CREATE_CHILD_SA -> 
> (dropped) (A3, B1, 55) CREATE_CHILD_SA -> (dropped) (A1, B2, 
> 55) CREATE_CHILD_SA -> Host B gets the packet..
> 
> He decides that the he should move the traffic to that new 
> address pair too, so he sends address update packet to host B:
> 
> retranmissions take the next case where we have also shorter 
> temporary failures or one way connections.
> 
> Host A notices that he is not getting anything back so he 
> starts searching for the working address pair:
> 
> (A2, B1, 57) DPD ->
> 
> Now host A gets the packet, and he notices that the 
> previously working path (A1, B2) does not work anymore, but 
> path (A3, B1) works, so he updates the SAs to that new address pair
> 
> all of them are finding the working address pair. After we 
> have found out the working address pair, we start the actual 
> movement request with the specific exchange N(UPDATE 
> ADDRESS). Of course also the N(UPDATE ADDRESS) packets gets 
> the same processing, i.e. if the packets do not get through 
> we start searching for the working address pair.
> 
> Depending on the protocol and contents of N(UPDATE ADDRESS) 
> we need to decide what we do if the address pair changes 
> during the N(UPDATE
> ADDRESS) exchange. I.e. if the addresses are also stored 
> inside the N(UPDATE ADDRESSES) then we can see that the 
> addresses of outer header and inside notify does not match, 
> so either there is NAT or the initiator needed to start 
> address pair search after construction the packet. In that 
> case B can either reject the update (NAT prevention) or 
> simply accept it.
> 
> If host A needed to start address pair search, and he didn't 
> like the result he can start searching new address pair and 
> when he has found the one he likes, he can redo the N(UPDATE 
> ADDRESS). 
> --
> [email-masked]

---

From: "Geoffrey Huang" <[email-masked]>
Date: Wed, 6 Apr 2005 10:04:34 -0700

The only hang-up I have is Jari's question below; namely, what exactly
constitutes "information needed to do mobility 
and path testing"?  It has to be fairly lightweight since the expectation is
that this information would be included in each packet.

-g

> [mailto:[email-masked]] On Behalf Of Stephane Beaulieu
> Sent: Wednesday, April 06, 2005 7:31 AM
> To: 'Tero Kivinen'; 'Jari Arkko'
> Cc: [email-masked]
> Subject: RE: [Mobike] issue 11 -- window size
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 6 Apr 2005 14:39:34 -0700

> vote that we proceed with this approach.
There is nothing wrong with Tero's proposal. I like it. But we should at least
look at other options. They are :

1) Define a separate window for PATH_TEST messages
2) Do the PATH_TEST message outside the protection IKE SA [MOPO protocol]

This gives the flexibility in what PATH_TEST messages contain. Otherwise, you have
to include all possible options with all the packets if you ever do MOBIKE for that
IKE SA. Once we know the new PATH,  rest of it follows as per Tero's mail.
Another advantage of keeping PATH_TEST message separate (like in (1) and (2)
above), is that we can look for a new PATH even when there is no failure. This
might be a useful feature. I don't know whether it is possible with Tero's proposal.

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 13:20:50 +0300

>  by just looking at the Message-id. 

You could do it also based only on the message-ids, but then you do
not notice if the other end is acting incorrectly (i.e. the packet
changes) etc. You also open reflection attack, as attacker need to
simply guess the message-id in use to be able to trig you to send
retransmission to forged addresses. If you do the hash, then attacker
must have also been seen the original packet too. Calculating and
storing the hash is already done by some implementations of IKEv2
(without mobike), just to protect agains those attacks, and as that is
how people do it in IKEv2, I used the same explination for the mobike.

The protocol does not require to do the hash, it works perfectly
without that too, but as there is implementations out there who do
calculate the hash (or store the whole packet), you cannot change the
packet after you have first time sent it. You can change the IP and
port, but you cannot add any payloads etc to it. IP and port are not
included in the HASH as the IKEv2 draft says you need to respond even
to the retransmission coming from different IP and port.

Actually for the authenticated packets, it is enough to store the MAC
of the packet...

> sent to the new place.

Responder does not detecth HASH change, as it does not change. The
HASH is calculated over the IKE packet, and that does (cannot) not
change. IP address and port are not covered by the hash.

> This implies that the retransmitted
> (except the IP header).

Yes. Retransmission == sending same packet again, so it MUST be
identical to the previous one, as it MUST be ignored by responder, but
MUST trigger retransmission of reply. 

> If any other change is in the payload, 
> then the stored response won't work.

Yes. 

> This might be a bit
> restrictive depending on how the protocol evolves.

This how it is done in the IKEv2, and I do not think we should be
changing it in the MOBIKE. 

> So, the main advantage and difference of moving the PATH_TEST
> message outside the normal window processing is that it can be a
> totally new message.

That is one option. I just explained another option, which does not
require it to be outside the normal window processing.

> Hence NAT-D need not be included in every
> message i guess.

That depends what we do for the NAT-T and MOBIKE. If we want MOBIKE to
work with NATs, we need to take IP-addresses from outer IP-header
anyways, so we do not necessary need any NAT-D packets.

> Perhaps, there might be something else in the

Yes, we might need the same processing anyways, so my suggestion was
that one option could be to simply use it always, thus there would not
be need for the separate PATH_TEST message.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 13:29:36 +0300

> PeerB to retransmit the response to A1 a few times, and then automatically

As only party doing retranmissions in the IKE is the initiator, the
PeerA would continue retransmitting the CREATE_CHILD_SA to the PeerB
as long as it does not get reply back.

After a while after it haven't received reply (or immediately when it
detects that A1 goes down) initiator (peerA) should start path
finding, i.e it should send next retranmission of packet:

A2 --> B1 (CREATE_CHILD_SA request)

PeerB would retransmit its reply to new IP-address

A2 <-- B1 (CREATE_CHILD_SA response)

And they have now finished the exchange, and continue processing. Now
next thing what PeerA would like to do, is probably update his
addresses to the PeerB, if A1 really went away, or at least move
existing IPsec SA traffic to use address pair of A2, B1 which is known
to work now (this update could also be automatic).

There are some other options how this protocol could be written, but
this is just one example how the protocol could be written (i.e.
mostly to give proof that we do not necessarely need PATH_TEST
exchange which is outside the window, or we do not necessarely need
window size > 1).
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 13:32:10 +0300

> post answers my questions.

Good. I hope my answer you your mail still clarifies things more. I
was planning to put the example in the first email already, but I had
some other interruptions, and noticed that I do not have time to do at
that point, so I sent the first description then and then came back
later to write the example of protocol.

Perhaps I should have waited with the first post until I had the
example done... 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 13:59:54 +0300

> that this information would be included in each packet.

Depending on the NAT issue, it could even be simply the IP-addresses
already there in the outer header. Especially if we do not do
automatic updates based on the path tests, but after we detect from
the path test that the IP-addresses pair has changed, we do actual
notification of movement as a separate exchange (which still gets the
same processing, so the packets will get trough and exchange ends even
when change happens again during that exchange).

Perhaps the largest thing that could be there would be list of
IP-addresses peer has, but I am not sure we need that. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 Apr 2005 14:06:28 +0300

> 1) Define a separate window for PATH_TEST messages

Hmm... I am not sure what you mean by that. Can you exlain it more.

> 2) Do the PATH_TEST message outside the protection IKE SA [MOPO

Yes, that is another option. I just send my proposal to offer another
option for that proposal :-)

> Another advantage of keeping PATH_TEST message separate (like in (1)
> and (2) above), is that we can look for a new PATH even when there
> is no failure. This might be a useful feature. I don't know whether
> it is possible with Tero's proposal.

My proposal didn't give out any exact details of the path test
process, but as it will be done for all packets, you can use DPD
packets to do it, for example you could make the DPD path test checks
so that they will always start the different address pair, so that
finding of list of working address pairs happens on the background
during the DPD tests. When the actual failure happens the path test
process could use that information too.

On the other hand, I do not think there is that much value for the old
information, as clearly something has changed in the paths as the
current (previously working address pair) has stopped working, thus
all the old information we have might be obsolete now anyways.

I think we need to separate the actual process how to send the
PATH_TEST packets (i.e. path test process, what IP address try, and in
which order, what information to use, what timers to use etc), from
the packet format used for the PATH_TEST packets (i.e. separate
PATH_TEST exchange, or any IKE packet). 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 7 Apr 2005 16:18:32 -0700

> how people do it in IKEv2, I used the same explination for the mobike.
Ok, thanks for the clarification.

> packet after you have first time sent it. You can change the IP and

This is an important point. The IKEv2 draft says:

   An IKE endpoint MUST keep a copy of (or be
   able to regenerate exactly) the number of previous responses equal to
   its declared window size in case its response was lost and the
   initiator requests its retransmission by retransmitting the request.

 It is hard to regenerate an exact copy without storing and hence implementations
store the packet i guess. We want to honor that here i guess.
Otherwise, the retransmitted message can change from the first time.

<snip>

> anyways, so we do not necessary need any NAT-D packets.
It depends on what you mean by working with NATs. If i move behind a NAT
(where there was no NAT previously), and want to detect NAT, Prevent NAT etc.
you want MOBIKE to work in these cases.

In a previous discussion on this mailing list, at least some of us felt that it should
work with NAT and taking addresses from the IP header should not be the only
way to do it. 

> be need for the separate PATH_TEST message.

Okay.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 7 Apr 2005 16:42:16 -0700

> Hmm... I am not sure what you mean by that. Can you exlain it more.
This is one way to do it, but not the only way to do it. Define a new flag
value indicating "Mobility messages". The message-id carried in the
IKE header has its own window space. Thus not constrained by
the current window used by "normal IKEv2 messages". This can
be used by PATH_TEST in the same way as you described. 
Message-ids can be used to match request to response and hence
you know which path works. Would that work ? 

> option for that proposal :-)
I am not sure i understood this. Are you saying that your PATH_TEST option
could be used by MOPO or something else ?

> process could use that information too.
Ok, the other end knows that it is "DPD path" test, so just reply and don't affect
the SAs. 

> all the old information we have might be obsolete now anyways.
Agreed that it is a potential problem. But perhaps it can be used 
as a hint to start trying from the address pair that was known to
work sometime back. Implementations can be smart enough to age the information
and periodically refresh. I think providing such a mechnaism is useful.

> PATH_TEST exchange, or any IKE packet). 

Agreed. The former is more implementation dependent and should
MOBIKE really say anything at all ? Also, note that which end does
the PATH_TEST has not been resolved yet i guess.

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 Apr 2005 10:42:19 +0300

>    initiator requests its retransmission by retransmitting the request.

This is different case. This is for the responses send based on the
request. 

>  It is hard to regenerate an exact copy without storing and hence
> implementations store the packet i guess. We want to honor that here
> i guess. Otherwise, the retransmitted message can change from the
> first time.

There are two cases there.

1) How to check that the request is same.
2) How to retransmit the response if retransmission of request is
found.

For 1) simply checking the message ID would be enough, but as people
do consider that somewhat bad to retransmit packet so easily, they
will store the hash of the request packet and use that to verify that
the retransmission is really a retransmission, not some random garbage
from net.

For 2) implementations need to store the response packet they are
sending back, or at least store enough information that they can
regenerate the previous packet exactly.

> In a previous discussion on this mailing list, at least some of us
> felt that it should work with NAT and taking addresses from the IP
> header should not be the only way to do it.

If you want it to work with NATs, your only option is to take
addresses from IP header. You can store information inside the packet
also to do detection of NAT, but you cannot really use that
information inside the packet for anything else than NAT detection.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 Apr 2005 10:52:37 +0300

> you know which path works. Would that work ? 

So to create overlay IKE SA message IDs using the same SPIs, but
separate flag to specify that you these messages are not constrained
by the window of normal message IDs? Yes, that would also work.

> could be used by MOPO or something else ?

Most of those options, could be used by most of the protocols. There
is nothing that exactly ties in the PATH_TEST message format and the
actual mobike protocol. Thats why we are now trying to decide which
one to use.

> Ok, the other end knows that it is "DPD path" test, so just reply
> and don't affect the SAs.

Yes. Of course it need to reply to the DPD packets all the time, and I
think we do not want to tie in path test and moving of SAs, i.e. in my
example I used separate information exchange sending notification
which actually made the changes to the SA addresses. I.e. the change
operation is explicitly done, instead of implictly happening after we
notice that path changed.

IKEv2 NAT-T does the implicit path changing, i.e. every time the
address changes then addresses of SAs are updated. I think mobike
should do explicit updating, but that is one option we need to decide
too. 

> MOBIKE really say anything at all ?

I think we need to give at least some implementation hints or
description how it could be done, so we have some kind of common way
of doing it. Exact details what information is used etc can be left to
implementations, as different implementations have different hints
available for them. 

> Also, note that which end does the PATH_TEST has not been resolved
> yet i guess.

That mostly depends on other questions, like if we do initiator
decides then he is the one doing path tests etc...
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 8 Apr 2005 17:00:16 -0700

> the retransmission is really a retransmission, not some random garbage
Sorry to beat up on the same point again.. The reason the retransmitted
request cannot change (except IP headers) is because it would break
implementations that store the hash of the request to detect retransmissions.
Is that right ?

> information inside the packet for anything else than NAT detection.
I was talking about  an "option" for detecting the presence of  NATs
securely where you don't accept blindly what you see in IP headers but also
check the payload (if address is present in the MOBIKE NAT-D
 payload) to see if the address on the IP header is same.

-mohan

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 9 Apr 2005 17:12:15 +0300

Yes.

> securely where you don't accept blindly what you see in IP headers but also

There is no way to detect NATs securely, unless you have co-operation
of NAT. NAT is an attacker on the way from initiator to the responder
who changes the IP-addresses. There is no way to distinguish that from
the real attacker, without changing NATs. 

>  payload) to see if the address on the IP header is same.

It is easy to securely detect that there is NO NAT between, and that
does not require changing of packets for retransmission. We simply
need to keep the other end up to date which addresses we might be
using, and if the address is one of those, then there is no NAT
between. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike