List Info

Thread: btns-ipsec-apireq.txt




btns-ipsec-apireq.txt
user name
2006-04-22 23:28:37
>>>>> "Miika" == Miika Komu
<miikaiki.fi> writes:
    >> What is the uniqueness requirements for the ED?
Is it just a locally
    >> allocated number that a host could start
assinging at 1 for the remote
    >> hosts it talks to?

    Miika> Currently yes. It could be unique only in the
process context,
    Miika> depending on the implementation.

<implementation detail alert>
  I am seriously considering making the EDs, which I think
of as first class
objects, be file descriptors.  Further, they may well be
Unix domain sockets
(perhaps with a new family type) that are already connected
to the
appropriate keying daemon.
</implementation detail alert>

(I think the HIP people might need to explain how HIP
opportunistic mode
differs from rfc4332. It isn't the same)

-- 
]       ON HUMILITY: to err is human. To moo, bovine.       
   |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON
   |net architect[
] mcrxelerance.com      http://www.san
delman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel
hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on
Linux." - orospakr

_______________________________________________
btns-ipsec-apireq.txt
user name
2006-04-23 22:16:27
On Sat, 22 Apr 2006, Michael Richardson wrote:

>>>>>> "Miika" == Miika Komu
<miikaiki.fi> writes:
>    >> What is the uniqueness requirements for the
ED? Is it just a locally
>    >> allocated number that a host could start
assinging at 1 for the remote
>    >> hosts it talks to?
>
>    Miika> Currently yes. It could be unique only in
the process context,
>    Miika> depending on the implementation.
>
> <implementation detail alert>
>  I am seriously considering making the EDs, which I
think of as first class
> objects, be file descriptors.  Further, they may well
be Unix domain sockets
> (perhaps with a new family type) that are already
connected to the
> appropriate keying daemon.
> </implementation detail alert>

Yes, this is true.

> (I think the HIP people might need to explain how HIP
opportunistic mode
> differs from rfc4332. It isn't the same)

It means that there is a leap of faith because the first
packet of the HIP 
key exchange is sent to an unkown HIP layer identifier
(=HIT). In 
practice, this might be a little bit problematic to
implement because the 
application might be doing a connect call on an IP address.
It is 
problematic in the sense of mobility; when hosts move, the
address may 
become invalid.

There are various ways to go around this problem which
mostly involve in 
wrapping or modifying the application sockets somehow,
either at the 
application layer or sockets layer in kernel. Compared to
them, ED makes 
things simpler because the HIT can be later on filled when
the HIT is 
actually learned later on during the key exchange.

-- 
Miika Komu              miikaiki.fi          http://www.iki.fi/miika/
_______________________________________________
[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )