Subject: Re: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txtFolks,

From: Julien Laganier <[email-masked]>
Date: Mon, 4 Jul 2005 16:58:48 +0200

Folks,

On Wednesday 22 June 2005 14:15, Pekka Nikander wrote:
>
> It looks like all text on how construct a proper R1 at the
> Responder end is missing, as well as how the Initiator
> verifies the received R1 with an VIA:RVS parameter.

I have a question about constructing the R1. In the current 
specification, it is said that a responder contacted via a RVS MAY 
use a LOCATOR parameter, in conformance with [hip-mm]. 

Is it okay with MAY or should we use SHOULD? 

And is it right to write: the initiator SHOULD accept packets with or 
without LOCATOR parameter.

Thanks.

--julien

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 4 Jul 2005 17:06:32 +0200

> use a LOCATOR parameter, in conformance with [hip-mm].

Hmm.  The source IP address should be correct in any case.

If the R1 would be returned via the RVS and include a LOCATOR
for the Responder's real IP address, that would sound fine to me.

If the R1 would contain the Responder's real IP address and
the VIA_RVS parameter (for tracking in the flooding case),
that would sound fine with me.  Adding a LOCATOR for the
Responder's real IP address sounds like redundancy, unless
the locator lists alternative IP addresses.

> Is it okay with MAY or should we use SHOULD?

So, maybe it still should be "MAY" but the draft to be clarified.

> without LOCATOR parameter.

No, LOCATOR will be defined in a different RFC, and IMHO we don't
want to have a hard dependency here.  The system should work with
the LOCATOR being optional in the sense that the association should
be formed even if the Initiator does not understand the LOCATOR
parameter.

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Mon, 4 Jul 2005 17:30:28 +0200

On Monday 04 July 2005 17:06, Pekka Nikander wrote:
> > specification, it is said that a responder contacted via a RVS
> > MAY use a LOCATOR parameter, in conformance with [hip-mm].
>

In the current version the R1 always goes directly to the Initiator.

> the locator lists alternative IP addresses.

Because the R1 always goes directly to the initiator it would always 
contain the responder's real IP address.

So it would always be redundant. 

> > And is it right to write: the initiator SHOULD accept packets
> > with or without LOCATOR parameter.
>

Perhaps we could simply remove all references to LOCATOR. That way we 
have no hard dependency, and no redundancy.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 4 Jul 2005 17:30:28 +0200

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 4 Jul 2005 18:45:06 +0200

> have no hard dependency, and no redundancy.

Sounds good to me.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 4 Jul 2005 18:45:06 +0200

Sounds good to me.

--Pekka

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 5 Jul 2005 11:10:00 +0200

> What requirement keyword should we use about the responder adding the
> VIA_RVS to an R1 when I1 was relayed. The current text has MUST, but
> I am now confused. Should it be only SHOULD?

I think it should be "MUST", as leaving it out might make the
system vulnerable to certain kind of reflection attacks.
That is, if the R1 is sent to a different address than what I1
was received from, the source address of I1 MUST be included in
the R1.  VIA_RVS is there exactly for this purpose.

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Tue, 5 Jul 2005 10:25:06 +0200

Folks,

Tnx.
-- 
julien

---

From: Petri Jokela <[email-masked]>
Date: Fri, 29 Jul 2005 15:17:09 +0300

Pekka Nikander wrote:
>>>> Because the state is indexed by source and destination HI/HITs,
>>>> and not IP address, I assume that we don't need specific text on
>>>> how to handle an R1 when a RVS was involved in I1 delivery, with
>>>> or without presence of a VIA_RVS parameter.
>>>>
>>>> Is that correct or I am missing something?
>>>
>>>
>>> Hmm.  I can see some implementations checking also the IP
>>> fields in incoming R1s in order to weed out potential replay
>>> attacks.  Hence, I think we should include a few sentences here
>>> stating the perhaps obvious:  that incoming R1s SHOULD be verified
>>> based on state on HITs only, and if IP addresses are checked,
>>> also include RVS to the check....
>>>
>>> Or what do you think?  Perhaps I am missing something?
>>
>>
>> No that is fine. Do you think we should have also a SHOULD requirement
>> for the case where IP address are also checked?
> 
> 
> FWIW, I think that the base spec should simply say that when matching
> an incoming R1, the IP addresses SHOULD be ignored and the match
> SHOULD be based on HITs only.  Of course, that is usually impossible
> for opportunistic connections, though.  The RVS spec could then state
> that if an implementation checks the IP addresses anyway, it MUST check
> for an VIA_RVS parameter and use that for matching.

I made a small addition to the incoming R1 packet handling:

 A system receiving an R1 MUST first check to see if it has
 sent an I1 to the originator of the R1 (i.e., it has a HIP
 association that is in state I1-SENT and that is
 associated with the HITs in the R1.  IP addresses in the
 received R1 packet SHOULD be ignored and the match SHOULD
 be based on HITs only). If so, it should process the R1 as
 described below.

Is this ok?

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 29 Jul 2005 14:27:57 +0200

>  be based on HITs only). If so, it should process the R1 as

Mention opportunistic mode, can't use HITs there?

Other than that OK.

--Pekka