[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Fwd: I-D ACTION:draft-nikander-multi6-hip-00.txt]
Hi Pekka,
A question about section 3.2: what do you mean by "update the state" when
the Recipient wants to open a connection in the reverse direction.
I think i understand the attack that you are trying to prevent here,
however, i am not sure that i really understand what do you mean by update
the state.
The attack, as i understand it could be the following
An attacker A wants to steal the identity of a Server S in a certain victim
B. Since the identity for the transport layer is the HIT, A wants to pretend
to be HITS in the eyes of B.
So, A initiates a communication with B, and A uses HITS as HIT and IPA as
address.
Since they are using LHIP, no validation about HITS is performed by A.
This is not really a problem I think because it is A who started the
communication, so it is hard to perform an attack.
The problem is when B wants to contact S, since if B accept the binding
between HITS and IPA, then it will be initiating a communication with A
thinking that it is communicating with S.(this is why you mention in your
draft that when the recipient wants to initiate a communication in the
reverse sense it has to be careful, right?)
Now, you state that the recipient in this case B has to update the state,
what does this means?
- Does it means that it has to obtains the IP addresses of the HIT again,
for instance from the DNS? and then it can use LHIP
- Does this means that it can initiate the reverse communication but it has
to perform the 4 way handshake validating the HIT? This would mean that LHIP
cannot be used in reverse communications, right?
- something else?
BTW i couldn't find draft-yitalo-multi6-hc, i guess it is not submitted yet.
A question about mobility: does the rendez vous server described in section
5.2.1.2.1 forwards packets to mobile hosts, like the Home Agent of mobileip,
or it just informs about the current address of the mobile node?
question about 5.2.2.3: hosts MUST verify reachability of an address before
start using it? i understood from recent mail exchanges at the HIP ml that
this was optional.
about 5.3.1.4- policy
How would the adoption of hip impact current default address selection
mechanism?
IMHO, hip would apply rfc 3484 to select addresses, right?
then you could use the policy table defined in rfc 3484 to express policy, i
think
about 5.3.1.8 - ingress filtering
I am not sure that what is stated in the draft in completely accurate...
Other multiaddress solutions propose concrete approaches to deal with
ingress filtering, for instance SIM uses source address rewriting by exit
routers. To support this they require a rewrite OK bit in the header, in
order to inform the exit router if this packet can be rewritten.
AFAIK, hip does not define something like this, and i am not sure if HIP
would work if all the source address of all packets is rewritten. In
particular, interaction with IPsec comes to my mind, and interaction with
legacy hosts.
Perhaps with some modifications hip could support this, but i don't really
know that.
There are other approaches to deal with ingress filtering that probably
could be directly supported by HIP, such as the ones presented in
draft-huitema-multi6-hosts.
regards, marcelo
> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Brian E Carpenter
> Enviado el: domingo, 25 de enero de 2004 17:00
> Para: Multi6
> Asunto: [Fwd: I-D ACTION:draft-nikander-multi6-hip-00.txt]
>
>
>
>
> -------- Original Message --------
> Subject: I-D ACTION:draft-nikander-multi6-hip-00.txt
> Date: Fri, 23 Jan 2004 15:59:31 -0500
> From: Internet-Drafts@ietf.org
> Reply-To: Internet-Drafts@ietf.org
> To: IETF-Announce: ;
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
>
>
> Title : draft-nikander-multi6-hip-00
> Author(s) : P. Nikander
> Filename : draft-nikander-multi6-hip-00.txt
> Pages : 28
> Date : 2004-1-23
>
> The Host Identity Protocol implements the identifier locator
> separation by introduing a new name space and a new layer to the IP
> stack. The new structure insulates the transport layer protocols
> from the internetworking layer, thereby allowing transport sessions
> to remain unaffected even if the underlying IP addresses change.
> That, in turn, seems to make it easier to solve the so called site
> multi-homing problem than without introducing such an indirection
> layer.
>
> This document discusses how the proposed HIP mobility and
> multi-homing solution, described separately, would fit to the IETF
> multi6 working group requirements.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of
> the message.
>
> 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-nikander-multi6-hip-00.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:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-nikander-multi6-hip-00.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.