Subject: [Hipsec] Rendezvous server

From: [email-masked] (Jan Mikael Melen)
Date: Mon Mar 29 23:54:01 2004

Hi,

On Monday 29 March 2004 19:36, Julien Laganier wrote:
> On Monday 29 March 2004 11:34, Jan Mikael Melen wrote:
>
> Perhaps requiring an HIP association all the time between a HIP node
> and its RVS is a bit onerous, especially for the RVS. As I1s are not
> authenticated anyway, we might obtain the same security guarantees by
> only requiring an HIP Association periodically, in order to create,
> update or renew a "soft HA", that would only consist in a an
> associated lifetime, Destination HIT and IP address. This would avoid
> storing on the RVS a full HA data structure with public keys and so
> on, thus increasing scalability.

"soft HA" would be nice and probably enough also in the case of sending
payload packets because the payload is not signed.

> [ snip... snip... snip... ]
>
> AFAICS, because I1 are not authenticated anyway, you could probably
> just  forward them after having rewrote the source address (for
> egress filtering) and adding a (new) TLV parameter with type
> FORWARDED_FROM, containing the source address of the initiator.

Yes, very true but this would mean that the responder should have a separate
logic for parsing I1s that have been forwarded and for I1s that have not been
forwarded (I'm just trying to save few lines of code ;).

> This mechanism can be exploited for DoS attacks (spoofing a RVS for
> sending I1 and create R1 storms), but it's not that different from
> the base protocol (the responder answers an I1 with a R1 without
> crypto checks).

Same problem exists with payload packets as well as those are not signed, not
at least according to current version of base protocol draft.

   - Jan

---

From: [email-masked] (Julien Laganier)
Date: Tue Mar 30 02:21:00 2004

On Tuesday 30 March 2004 07:40, Jan Mikael Melen wrote:
> > Perhaps requiring an HIP association all the time between a HIP
> > node and its RVS is a bit onerous, especially for the RVS. As I1s
> > are not authenticated anyway, we might obtain the same security
> > guarantees by only requiring an HIP Association periodically, in
> > order to create, update or renew a "soft HA", that would only
> > consist in a an associated lifetime, Destination HIT and IP
> > address. This would avoid storing on the RVS a full HA data
> > structure with public keys and so on, thus increasing
> > scalability.
>
> "soft HA" would be nice and probably enough also in the case of
> sending payload packets because the payload is not signed.

Yep.

> > AFAICS, because I1 are not authenticated anyway, you could
> > probably just  forward them after having rewrote the source
> > address (for egress filtering) and adding a (new) TLV parameter
> > with type FORWARDED_FROM, containing the source address of the
> > initiator.
>
> Yes, very true but this would mean that the responder should have a
> separate logic for parsing I1s that have been forwarded and for I1s
> that have not been forwarded (I'm just trying to save few lines of
> code ;).

The logics doesn't need to be 'really' separate, it's just a matter of 
rewriting the source address and strip the TLV FORWARDED_FROM before 
entering the I1 processing per se. 

Related to code complexity, while it's true that PAYLOAD can be reused 
for other tasks (like piggybacking a SYN_SENT with I2), IMHO it's far 
more complex to implement TLV encapsulation than parsing a 4 or 
16-byte length TLV.

> > This mechanism can be exploited for DoS attacks (spoofing a RVS
> > for sending I1 and create R1 storms), but it's not that different
> > from the base protocol (the responder answers an I1 with a R1
> > without crypto checks).
>
> Same problem exists with payload packets as well as those are not
> signed, not at least according to current version of base protocol
> draft.

Right.

Does other HIPpies have an opinion on that topic?

--julien

---

From: [email-masked] (Kristian Slavov)
Date: Tue Mar 30 03:22:01 2004

> more complex to implement TLV encapsulation than parsing a 4 or 

If the new TLV is optional then all hosts might not process it. In this case 
they will send an R1 to the RvS. The RvS will not reply with I2 as the 
destination HIT in the R1 will be unknown.

If the new TLV is mandatory we will need to modify all implementations.
However, I think this modification is trivial.

> Does other HIPpies have an opinion on that topic?

I'd rather extend the I1 than implement the PAYLOAD packet :)
Also I don't think extending the I1 will bloat the base protocol. Even if this 
feature could be done by other means and thus not touch the base mechanism.
The RvS is an integral part of the HIP architecture. The protocol should have 
more or less explicit support for it.

-- 
Kristian Slavov

---

From: [email-masked] (Lars Eggert)
Date: Tue Mar 30 03:38:01 2004

This is a cryptographically signed message in MIME format.

--------------ms010707040400020508000003
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Julien & others,

> Does other HIPpies have an opinion on that topic?

I've been following the rendezvous thread with great interest. In Seoul, 
we've talked about splitting draft-eggert-hip-rendezvous into two 
separate documents, one discussing the I1-only mechanism and a second 
one focusing on the HIP-to-non-HIP mechanisms. (The second one is 
targetted at the RG.)

Much of the current discussion (run HIP between rendezvous server and 
mobile HIP node, relay I1 packets between the two, maybe using some sort 
of tunnel) could go directly into the I1-only document.

Unfortunately, I'll probably not be able to spend much time on 
HIP-related tasks this month, but I may be able to update the ID 
accordingly in May. If that's too late, I'd be happy to integrate text 
from the group before then.

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--------------ms010707040400020508000003
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms010707040400020508000003--

---

From: [email-masked] (Julien Laganier)
Date: Tue Mar 30 03:43:01 2004

On Tuesday 30 March 2004 11:08, Kristian Slavov wrote:
> >>Yes, very true but this would mean that the responder should have
> >> a separate logic for parsing I1s that have been forwarded and
> >> for I1s that have not been forwarded (I'm just trying to save
> >> few lines of code ;).
> >
> > The logics doesn't need to be 'really' separate, it's just a
> > matter of rewriting the source address and strip the TLV
> > FORWARDED_FROM before entering the I1 processing per se.
> >
> > Related to code complexity, while it's true that PAYLOAD can be
> > reused for other tasks (like piggybacking a SYN_SENT with I2),
> > IMHO it's far more complex to implement TLV encapsulation than
> > parsing a 4 or 16-byte length TLV.
>
> If the new TLV is optional then all hosts might not process it. In
> this case they will send an R1 to the RvS. The RvS will not reply
> with I2 as the destination HIT in the R1 will be unknown.

Right, they'll drop it (or forward it to the initiator if the RVS have 
kept some state in between.... not a very good idea though)

But, if a HIP node register with a RVS and published its address 
(e.g., in the DNS), then we can legitimately suppose that this node 
needs RVS functionnalities. IMHO, such a HIP node MUST support the 
FORWARDED_FROM TLV, while we can keep it optionnal for other HIP 
nodes.

> If the new TLV is mandatory we will need to modify all
> implementations. However, I think this modification is trivial.

I think so.

> Also I don't think extending the I1 will bloat the base protocol.
> Even if this feature could be done by other means and thus not
> touch the base mechanism. The RvS is an integral part of the HIP
> architecture. The protocol should have more or less explicit
> support for it.

I agree.

--julien