Subject: [Hipsec] Fwd: I-D ACTION:draft-ietf-hip-rvs-02.txt

From: Lars Eggert <[email-masked]>
Date: Fri, 17 Jun 2005 10:08:54 +0200

For some reasons, this announcement hasn't made it to the list yet.

We'd appreciate comments on this revision!

Begin forwarded message:

> From: [email-masked]
> Date: June 16, 2005 21:50:02 GMT+02:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-hip-rvs-02.txt
> Reply-To: [email-masked]
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Host Identity Protocol Working  
> Group of the IETF.
>
>     Title        : Host Identity Protocol (HIP) Rendezvous Extension
>     Author(s)    : J. Laganier, L. Eggert
>     Filename    : draft-ietf-hip-rvs-02.txt
>     Pages        : 16
>     Date        : 2005-6-16
>
> This document discusses a rendezvous extension for the Host Identity
>    Protocol (HIP).  The rendezvous extension extends HIP and the HIP
>    registration extension for initiating communication between HIP  
> nodes
>    via HIP rendezvous servers.  Rendezvous servers improve  
> reachability
>    and operation when HIP nodes are multi-homed or mobile.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-02.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body  
> of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the  
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>     "get draft-ietf-hip-rvs-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>     [email-masked].
> In the body type:
>     "FILE /internet-drafts/draft-ietf-hip-rvs-02.txt".
>
> NOTE:    The mail server at ietf.org can return the document in
>     MIME-encoded form by using the "mpack" utility.  To use this
>     feature, insert the command "ENCODING mime" before the "FILE"
>     command.  To decode the response(s), you will need "munpack" or
>     a MIME-compliant mail reader.  Different MIME-compliant mail  
> readers
>     exhibit different behavior, especially when dealing with
>     "multipart" MIME messages (i.e. documents which have been split
>     up into multiple messages), so check your local documentation on
>     how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 22 Jun 2005 17:15:29 +0300

Comments:

Consider removing or greatly condensing the first two
paragraphs from Introduction, and mostly replacing them
with a reference to the arch document.  I don't think this
kind of architectural discussion belongs to this kind of
a fairly-low-level protocol description.  But YMMV.
If you decide to make this change, also update the beginning
of the third paragraph to reflect what is above in the
new revision.

If you want to have architectural discussion in the beginning,
I would refer to the mobility discussion in the original
Mobile IP(v4) architecture paper by Bhagwat, Tripathi and
Perkins (1995), and discuss the need for a rendezvous point
in the light of that (see the section about Location Directory).

In the spirit of the above, I would also propose removing
or rewriting the first paragraph of section 3.

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.

[12] needs to be a normative reference due to the text
in section 3, third para after Figure 1.

Minor:

Sec 3.3:

>    If a HIP node and one of its rendezvous servers have a rendezvous
>    registration, the rendezvous servers MUST relay inbound I1 packets

Why the "MUST" here?  What danger is avoided?  I would just say
"servers relay" without the must.

>    Because of egress filtering on the path from the RVS to the client, 
> a
>    HIP rendezvous server MAY also need to replace the source IP 
> address,

I think this "MAY" should be a "SHOULD", i.e., replacing the IP address
is the RECOMMENDED way of doing it.  Also update 4.4. to reflect this.

>    The RVS MUST verify the checksum field of an I1 packet doing any

A missing "before" here?  Also, the "MUST" should be a "SHOULD" because
no danger to external nodes or security is involved if the RVS doesn't
check the incoming checksum.

Is there some text missing between the last and second last paras of
Sec 3.3?  I1 doesn't include SIG or HMAC paras, don't they?

Sec 4.5:

>   When a rendezvous server receives an I1 whose destination HIT is not
>    its own, it MUST consult its registration database to find a
>    registration for the rendezvous service established by the HIT 
> owner.
>    If it finds an appropriate registration, it MUST relay the packet to
>    the registered IP address.  If it does not find an appropriate
>    registration, is MUST drop the packet.

Inappropriate "MUST"s (all three of them)?

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Fri, 24 Jun 2005 15:41:52 +0000

Pekka,

Thanks for reviewing the draft. I agree with your comments, hence if 
no contradictory opinions are expressed, I will update the I-D 
accordingly. I have however one question regarding the validation of 
an R1.

> verifies the received R1 with an VIA:RVS parameter.

I will add text on how to construct a proper R1. 

Now concerning the validation of an incoming R1 in presence of a RVS, 
my understanding was that the VIA_RVS parameter was mainly intended 
to help debugging, and has only an informal nature and does not 
modify processing of the packet itself (hence its position after the 
signature in R1). Consequently I thought that processing an incoming 
R1 replying to a relayed I1 is no different from processing a 
"regular" R1. The base specification says:

	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 is in state I1-SENT).

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? Perhaps we might also want 
to consider the case where the responder want to securely assert its 
RVS IP address to the initiator, but I am really not sure about that.

Any insights appreciated. Thanks.

--julien

-- 
julien

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 25 Jun 2005 12:12:12 +0300

> 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?

> Perhaps we might also want

Hmm.  If we want add that, it should be in R2, I think.

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Mon, 27 Jun 2005 16:11:21 +0000

> > 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.
> >

No that is fine. Do you think we should have also a SHOULD requirement 
for the case where IP address are also checked?

> > to consider the case where the responder want to securely assert
> > its RVS IP address to the initiator, but I am really not sure
> > about that.
>

Ok. Not sure we want it, so I'll not consider it further.

Thanks.

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 29 Jun 2005 22:57:10 +0200

> 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.

--Pekka