Subject: Re: [Hipsec] I-D ACTION:draft-ietf-hip-rvs-05.txt

From: Julien Laganier <[email-masked]>
Date: Fri, 1 Sep 2006 09:39:52 +0200

Hi Andrei,

That's a bug in the draft, should be MUST in both places. Will fix it 
in next rev.

Thanks.

--julien

On Friday 18 August 2006 16:35, Andrei Gurtov wrote:
> Hi,
>
> I would like to ask if VIA parameter is mandatory or not. Currently
> the draft seems not clear on this, the first paragraph tells that
> responder may include addresses, while second tells it must do so
>
> After the responder receives a relayed I1 packet, it can begin to
>    send HIP packets addressed to the initiator's IP address,
> without further assistance from an RVS.  For debugging purposes, it
> MAY include a subset of the IP addresses of its RVSs in some of
> these packets.  When a responder does so, it MUST append a newly
> created VIA_RVS parameter at the end of the HIP packet.
>
>
> 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.
>
>
>
> Andrei
>
> [email-masked] wrote:
> > 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-05.txt
> > 	Pages		: 15
> > 	Date		: 2006-6-7
> >
> > This document defines 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-05.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-05.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-05.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.
> >
> > -----------------------------------------------------------------
> >-------
> >
> > _______________________________________________
> > Hipsec mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/hipsec

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

---

From: Julien Laganier <[email-masked]>
Date: Fri, 1 Sep 2006 10:16:04 +0200

Folks,

[ Sorry to reply to myself, I shot too fast ]

The initial requirement keyword for VIA_RVS was MAY as it's been 
thought as a debugging tool, but then Pekka suggested that it should 
be a MUST so that it can be used to mitigate possible reflection 
attacks [1]. Because that was then the consensus in the working group 
I changed the requirement keyword but kept the text as is. I now 
think the text should be changed to reflect the real intent. I 
propose the following:

   After the responder receives a relayed I1 packet, it can begin to
   send HIP packets addressed to the initiator's IP address, without
   further assistance from an RVS.  Because in that case the R1 is
   sent to a different address than what I1 was received from, the
   responder MUST include the source address of the I1 as the first
   address in a VIA_RVS parameter included in the R1.  This is meant
   to avoid introducing opportunities for certain kind of reflection
   attacks. For debugging purposes, the responder MAY also include a
   subset of the IP addresses of its RVSs as additional addresses in
   the VIA_RVS parameter.  To do so, the responder MUST append a newly
   created VIA_RVS parameter at the end of the HIP packet.

Does the WG agree?

Another related question is that the current VIA_RVS parameter has 
been placed intentionally after the SIG parameter so that it it's 
never signed. The rationale behind that was, when multiple RVSs are 
cascaded, to allow intermediate RVS's to include the IP address of 
the upstream RVS in I1s so that it's not lost. The current draft 
doesnn't have anymore provision for cascaded RVS, so I thought that 
it would be better to place VIA_RVS before SIG so that it's signed. 
What do you think?

Best,

--julien

[1] http://www1.ietf.org/mail-archive/web/hipsec/current/msg01435.html

On Friday 01 September 2006 09:39, Julien Laganier wrote:
> Hi Andrei,
>
> That's a bug in the draft, should be MUST in both places. Will fix
> it in next rev.
>
> Thanks.
>
> --julien
>
> > I would like to ask if VIA parameter is mandatory or not.
> > Currently the draft seems not clear on this, the first paragraph
> > tells that responder may include addresses, while second tells it
> > must do so
> >
> > without further assistance from an RVS.  For debugging purposes,
> > it MAY include a subset of the IP addresses of its RVSs in some
> > of these packets.  When a responder does so, it MUST append a
> > newly created VIA_RVS parameter at the end of the HIP packet.
> >
> >
> > append to the regular R1 header a VIA_RVS parameter containing
> > the IP addresses of the traversed RVS's.
> >
> >
> >
> > Andrei
> >
> > > between HIP nodes via HIP rendezvous servers.  Rendezvous
> > > servers improve reachability and operation when HIP nodes are
> > > multi-homed or mobile.
> > >
> > > 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
> > > 	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.
> > >
> > > ---------------------------------------------------------------
> > >-- -------
> > >

---

From: Julien Laganier <[email-masked]>
Date: Thu, 14 Sep 2006 16:10:43 +0200

Folks,

So far I received no response to the message below, so I assume that 
consensus is:

- to use the new text regarding requirement level of VIA_RVS
- to keep the existing VIA_RVS parameter placement (i.e. after SIG)

--julien

On Friday 01 September 2006 10:16, Julien Laganier wrote:
> thought as a debugging tool, but then Pekka suggested that it
> should be a MUST so that it can be used to mitigate possible
> reflection attacks [1]. Because that was then the consensus in the
> working group I changed the requirement keyword but kept the text
> as is. I now think the text should be changed to reflect the real
> intent. I propose the following:
>
>    After the responder receives a relayed I1 packet, it can begin
> to send HIP packets addressed to the initiator's IP address,
> without further assistance from an RVS.  Because in that case the
> R1 is sent to a different address than what I1 was received from,
> the responder MUST include the source address of the I1 as the
> first address in a VIA_RVS parameter included in the R1.  This is
> meant to avoid introducing opportunities for certain kind of
> reflection attacks. For debugging purposes, the responder MAY also
> include a subset of the IP addresses of its RVSs as additional
> addresses in the VIA_RVS parameter.  To do so, the responder MUST
> append a newly created VIA_RVS parameter at the end of the HIP
> packet.
>
> Does the WG agree?
>
> -- julien

---

From: Miika Komu <[email-masked]>
Date: Thu, 14 Sep 2006 21:19:48 +0300 (EEST)

> - to keep the existing VIA_RVS parameter placement (i.e. after SIG)

This seems to be fine IMHO.

-- 
Miika Komu                                       http://www.iki.fi/miika/

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 19 Sep 2006 16:23:17 -0700

sorry for the late reply

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Friday, September 01, 2006 1:16 AM
> To: [email-masked]
> Subject: [Hipsec] VIA_RVS parameter (Was: 
> I-DACTION:draft-ietf-hip-rvs-05.txt)
> 
> Folks,
> 

- I would clarify "source address of the RVS-relayed I1" instead of
"source address of the I1"

- As presently defined, I do not know what these "other addresses in the
VIA_RVS" would be.  I think this text is left over from cascading RVS
use case.  I recommend to either delete or clarify what these multiple
addresses may be.

> it would be better to place VIA_RVS before SIG so that it's signed. 

I think that including VIA_RVS within signature range works against the
goal of being able to generate presigned R1s, so I would prefer to leave
it outside.

Other comments:

- the draft is a bit unclear how to handle the FROM parameter in Section
4.3.2 (that the R1 MUST use the address in the first FROM parameter as
the destination IP address for the R1).

- In section 4.3.4, it is stated:

   In case the IP addresses are also checked, then the source IP address
   MUST be checked against the IP address included in the VIA_RVS
   parameter.

I think that this should say:

   In case the IP addresses are also checked, then the destination IP
   address of the original I1 MUST be checked against one of the
   addresses included in the VIA_RVS parameter.

or else I am misunderstanding something.

Tom