Subject: [Hipsec] Question about RVS_HMAC

From: Jan Mikael Melen <[email-masked]>
Date: Thu, 5 Jan 2006 14:20:13 +0200

Hi,

The draft-ietf-hip-rvs-04 defines that one should add an RVS_HMAC after the 
FROM parameter when forwarding the I1, but if a node has multiple RVS servers 
how can the client determine the RVS server that created the RVS_HMAC? 

In the forwarded I1 packet there is nothing that would reveal the identity of 
the RVS server which forwarded the I1? Has anyone else implemented this kind 
of scenario and if yes how have you solved the problem? Are you searching the 
RVS using the source IP address of the packet (and how do you determine the 
IP address if the client is behind NAT)?

Maybe I've just missed some important piece of information as I read the 
draft.

  Regards,
     Jan

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

---

From: Miika Komu <[email-masked]>
Date: Mon, 9 Jan 2006 17:33:39 +0200 (EET)

On Thu, 5 Jan 2006, Jan Mikael Melen wrote:

> The draft-ietf-hip-rvs-04 defines that one should add an RVS_HMAC after
> the FROM parameter when forwarding the I1, but if a node has multiple
> RVS servers how can the client determine the RVS server that created the
> RVS_HMAC?
>
> In the forwarded I1 packet there is nothing that would reveal the
> identity of the RVS server which forwarded the I1? Has anyone else
> implemented this kind of scenario and if yes how have you solved the
> problem? Are you searching the RVS using the source IP address of the
> packet (and how do you determine the IP address if the client is behind
> NAT)?
>

I think you are right. In current approach, only a single RVS has been
considered. The responder needs to verify the HMAC in the I1 against all
of the integrity keys of its rendezvous servers. Seems like the HIT of the
RVS needs to be include in the I1 somehow.

I had also some other thoughts when reading the draft:

  * Terminology: I think the term "client" should be always referred as
    the "rendezvous client" or just "responder". At least for me, it was
    slightly confusing that the rendezvous _client_ means responder
    (usually the "client" is assumed to be the initiator). Maybe
    preferring the word "responder" instead of "client" could clear out
    some of confusion (especially in the last two paragraphs of 4.3.2).

  * The HIT should be added also in the case of cascading rendezvous
    servers, not only parallel. (Slightly off-the topic: how do the
    cascades work with the DNS records?)

  * I don't know if it has been proposed already but could LOCATOR be
    embedded inside the FROM or VIA_RVS parameters. Or reused in another
    way to avoid redundancy?

  * There is a mismatch in the MAY/MUST statements of two sections:

      4.3.2. For debugging purposes, it MAY
      include a subset of the IP addresses of its RVSs [i.e VIA_RVS
      parameters] in some of these packets.

      4.3.3. When a responder replies to an I1 relayed via an RVS, it MUST
      append to the regular R1 header a VIA_RVS parameter containing the
      IP addresses of the traversed RVS's.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: Jan Mikael Melen <[email-masked]>
Date: Tue, 10 Jan 2006 15:44:09 +0200

Hi,

> RVS needs to be include in the I1 somehow.

Would be okay to include the whole HI of the rendezvous server then we 
wouldn't have to define a new TLV only new TLV type number for RVS_HI.

  Regards,
     Jan

---

From: Julien Laganier <[email-masked]>
Date: Mon, 16 Jan 2006 11:56:54 +0100

Hi Jan,

On Thursday 05 January 2006 13:20, Jan Mikael Melen wrote:
> Hi,
>
> The draft-ietf-hip-rvs-04 defines that one should add an RVS_HMAC
> after the FROM parameter when forwarding the I1, but if a node has
> multiple RVS servers how can the client determine the RVS server
> that created the RVS_HMAC?
>
> implemented this kind of scenario and if yes how have you solved
> the problem? Are you searching the RVS using the source IP address
> of the packet (and how do you determine the IP address if the
> client is behind NAT)?

I did not implement the RVS support, but the source IP address of the 
I1 can be used as an index to the right RVS registration and key. It 
seems that there's no issue if the client is behind a NAT because 
only the client IP address would be translated, not the RVS one.

What does other people think?

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 16 Jan 2006 11:56:54 +0100

Hi Jan,

--julien

---

From: Miika Komu <[email-masked]>
Date: Mon, 16 Jan 2006 13:16:25 +0200 (EET)

> What does other people think?

Maybe we can later have also the server behind the NAT.

---

From: Julien Laganier <[email-masked]>
Date: Tue, 17 Jan 2006 10:30:57 +0100

On Monday 16 January 2006 12:16, Miika Komu wrote:
> > I did not implement the RVS support, but the source IP address of
> > the I1 can be used as an index to the right RVS registration and
> > key. It seems that there's no issue if the client is behind a NAT
> > because only the client IP address would be translated, not the
> > RVS one.
> >

Well, if the RVS is behind a NAT, a second RVS would be required in 
front of the NAT to make packet pass through the NAT up to the RVS 
behind it.

In that case we would end up with two cascaded RVS, and this scenario 
was ruled out by the WG before -01 was issued. 

IMHO we should not try to add support for this scenario now, and 
rather publish the draft ASAP as an EXPERIMENTAL RFC, and start 
experimentation. If later on it appears that there is interest in 
supporting such scenarios, we can still revise the RFC.

Other opinions?

--julien

---

From: Lars Eggert <[email-masked]>
Date: Tue, 17 Jan 2006 10:41:20 +0100

> supporting such scenarios, we can still revise the RFC.

I agree with you. We're talking about corner cases here that the rest  
of HIP doesn't support now - why is it important *at this time* that  
this experimental extension support it?

(I'm fine with putting a statement into the current version that says  
that we're aware of the issue, if people would like that.)

Lars
--
Lars Eggert                                     NEC Network Laboratories

---

From: Miika Komu <[email-masked]>
Date: Tue, 17 Jan 2006 12:34:15 +0200 (EET)

> that we're aware of the issue, if people would like that.)

Fine by me.

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 19 Jan 2006 12:14:33 +0200

> Fine by me.

Works for me, too.

--Pekka