headers
Jan Mikael Melen | 2 Apr 2005 11:54

HIP4BSD source code

Hi,

There is now available new version of the HIP4BSD source code at 
http://www.hip4inter.net/

We have also a HIP test server running at our lab. The HIT of that server can 
be resolved from the AAAA record of either woodstock4.hip4inter.net or 
woodstock6.hip4inter.net. Naturally the woodstock4 resolves also as an IPv4 A 
record and woodstock6 resolves as an IPv6 AAAA record. On error during the 
base exchange an NOTIFY message will be sent and approriate error code is 
set.

Both the code at hip4inter.net and the test server are implementing the 
draft-ietf-base-01 draft.

  Regards,
    Jan
Permalink | Reply | 0 comments |
headers
Julien Laganier | 4 Apr 2005 11:41
Favicon

Re: Rendezvous and tunneling

On Wednesday 30 March 2005 21:08, Henderson, Thomas R wrote:
> -----Original Message-----
> > So I have now three questions before I begin another pass of
> > edition:
> >
> > 1) Should we get rid of I1_TUNNELING mode?
> >
> > 2) Should we get rid of BIDIRECTIONAL mode? If not, what is
> > the usage scenario you have in mind?
> > 
> > 3) Should we specify that the RVS relays I1 _and_ UPDATES? This
> > is required to support double-movement in mobility scenarios.
>
> I am fine with 1 and 2.  As for 3, note that the current mobility
> draft does not address the double-jump problem from the client
> side. Therefore, if UPDATE inclusion gets hairy (i.e., has DoS
> issues), then I would not delay the RVS draft on account of that. 
> On the other hand, if it is a simple extension, then it will
> probably be used by future mobility drafts.

Ok, then I will proceed with (1) and (2). 

Regarding (3), I don't think there's is additional DoS issues we 
should be concerned about.

Potentials attacks involving UPDATE relaying are likely to be less 
severe than those involving I1: The I1 relaying introduces reflexion 
and amplification (because R1 is larger than I1) attacks.

The RVS draft defends against these attacks by HMACing packets relayed
(Continue reading)

Permalink | Reply | 501 comments |
headers
Pekka Nikander | 4 Apr 2005 14:35

Re: sticking with 128-bit HITs (was Re: SHA1 broken? )

Tom,

>>> That describes the essential bit of what I was trying to get at by
>>> proposing we just have a byte with one or two assigned code points.
>>> So if we say this:
>>>
>>>    If the prefix is 01000,
>>>    then the next 3 bits are the HA.
>>>
>>>    If the prefix is something other than 01000, then the syntax and
>>>    semantics of the following bits (however many there may be)
>>>    are to be defined by future documents.
>>>
>>> that makes me happy.
>>
>> I'm happy with that, too.
>
> Can we make it 010, with five bits HA?

Why that way?  Why not five bit prefix and three HA?  IMHO
three bits for the hash algorithm should be enough at this
point of time.  What is your rational for this different
allocation of the bits?  I feel that I am lacking information
here.  From my point of view, 3 bits is more than enough for
the hash algorithm (IMHO 2 bits would do), so I don't see any
reason for making it longer.  Secondly, making the prefix longer
is good from a potential IANA allocation point of view.  Sure,
we could do a still longer prefix, e.g. /13, but that would then
make the hash field considerably shorter and thereby less secure.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henderson, Thomas R | 4 Apr 2005 15:40
Picon
Favicon

RE: sticking with 128-bit HITs (was Re: SHA1 broken? )


> -----Original Message-----
> From: Pekka Nikander [mailto:pekka.nikander <at> nomadiclab.com] 
> Sent: Monday, April 04, 2005 5:36 AM
> To: Henderson, Thomas R
> Cc: Tim Shepard; hipsec <at> honor.trusecure.com
> Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] 
> SHA1 broken? ) 
> 
> Tom,
> 
> >>> That describes the essential bit of what I was trying to 
> get at by 
> >>> proposing we just have a byte with one or two assigned 
> code points.
> >>> So if we say this:
> >>>
> >>>    If the prefix is 01000,
> >>>    then the next 3 bits are the HA.
> >>>
> >>>    If the prefix is something other than 01000, then the 
> syntax and
> >>>    semantics of the following bits (however many there may be)
> >>>    are to be defined by future documents.
> >>>
> >>> that makes me happy.
> >>
> >> I'm happy with that, too.
> >
> > Can we make it 010, with five bits HA?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pekka Nikander | 4 Apr 2005 16:01

Problems with the current mailing list situation

Folks,

I am primarily sending this to the people that read the archives
and may be sending mail to the list without subscribing to it.
In theory that should work, but in practise it does not work right
now.  All posts by people not on the list need to be approved by
a moderator, and I happen to be that moderator.  For a number of
reasons I failed to handle the posts for a few weeks, with the
result that there is currently about 350 mails queued in the
moderator queue.  Most, if not all, of that is spam.  The only
spam filter that we have had was me.

Now, unfortunately, Safari fails to process the mailman admin web
page any more, because it is so big.  Or it does, but it gets so
painfully slow that it is unusable in practise, taking several
minutes to render the page, and then over a minute every time I
click on some widget.  Hence, right now I can't do anything to
process the moderator queue, and it therefore just accumulates.
As a result, if someone sends a legitimate message without being
on the list, it will never get processed.

I am sorry about the situation, but I don't have the cycles to do
anything right now.  We are in the process of moving the list to
another host, but that hasn't happened yet.  However, that doesn't
help with the current queue, which most probably will remain
unprocessed forever.

--Pekka
Permalink | Reply | 0 comments |
headers
Pekka Nikander | 6 Apr 2005 07:54

Re: some questions regarding the update packet protocol

Greg,

[CC:n to the list as I think this belongs to the WG and
raises important topics.]

>> UPDATEs MAY be retransmitting without incrementing SEQ.  ...
>
> How to process equal sequence numbers due (normally) to 
> retransmissions is
> outlined in section 8.10.1.  But what is the difference between
> retransmission and a replay attack?  Nothing as far as I can tell?

IIRC, the intention is to say that as packets may get duplicated in
the IP network anyway, also the sending host may send duplicate packets.
For example, if the sender does not receive a corresponding ACK, it
may resend an old, already signed packet instead of constructing a new
packet and signing that.

 From the receiver's perspective, it is no different from receiving
a recent packet multiple times.  The receiver does not know if the
packet has been duplicated in the net, is a replay attack attempt,
or has been resent by the sender.

Maybe the text needs to be clarified?

>
>> If the same
>>   subset of parameters is included in multiple UPDATEs with different
>>   SEQs, the host MUST ensure that receiver processing of the 
>> parameters
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henderson, Thomas R | 7 Apr 2005 01:33
Picon
Favicon

RE: Null IPsec


> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo <at> ericsson.com] 
> Sent: Wednesday, March 09, 2005 3:20 PM
> To: HIP
> Cc: David Ward
> Subject: [Hipsec] Null IPsec
> 
> Folks,
> 
> during today's meeting, the chairs got an action point to 
> talk to the security ADs about the possibility of having a 
> MUST implement IPsec with null encryption and/or null 
> integrity protection.
> 
> I talked to Russ, and his gut reaction was that null 
> encryption with integrity may be fine, but he would need to 
> see the use case people have in mind before accepting null 
> encryption and null integrity.
> 

We should probably try to close out this issue.

At the WG meeting, I asked whether having ESP as a MUST implement
portion of HIP would constrain future implementations that might not
need to run ESP.  Specifically, I had in mind Secure RTP (RFC 3711).
HIP plus SRTP could be implemented for a VoIP node, without ESP.

IIRC, Pekka pointed out that there is usually required a minimal level
of interoperability specified, and by putting out HIP as a stand-alone
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gonzalo Camarillo | 7 Apr 2005 10:19
Picon
Favicon

Minutes of HIP meeting in IETF 62

Folks,

here you have the draft minutes of our last meeting. Let us know if you 
have any comments.

http://hip.piuha.net/meetings/ietf62/notes/minutes-ietf62-hip.txt

Thanks,

Gonzalo
Permalink | Reply | 0 comments |
headers
Greg Perkins | 7 Apr 2005 20:47

Re: Re: some questions regarding the update packet protocol

Thanks for your responses Pekka, making update packets less useful to
attackers is going to be a little more complex than I thought.

> IIRC, the intention is to say that as packets may get duplicated in
> the IP network anyway, also the sending host may send duplicate packets.
> For example, if the sender does not receive a corresponding ACK, it
> may resend an old, already signed packet instead of constructing a new
> packet and signing that.
Ok, fair enough.

> IIRC, the intention is just to clarify the semantics.  For example,
> let say that we have a hypothetical payload "Increment a counter by
> one".
> Now, if you send two identical UPDATEs with the *same* SEQ, both
> containing
> the "increment a counter by one", the counter will be incremented once.
> However, if you send two UPDATEs with *different* SEQs but otherwise
> identical, the counter will be incremented twice.
>
> This is probably too obvious, and hence some text clarification might
> be needed.  Suggestions?
>
> Or maybe we should write more text about the perhaps-obvious semantics
> issue that the sender must not assume anything about the receiver's
> state beyond acked UPDATEs.  That is, if the sender has several pending
> updates out, the protocol must work correctly independent on which of
> the
> pending updates actually reach the receiver and in which order.
Ok, I think I get this now.  I think the protocol should not send another,
different update packet until a current outstanding update packet is acked
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miika Komu | 7 Apr 2005 22:10
Picon
Picon
Favicon

clarifications to the base draft

Thomas asked for Jeff and me to make some (interop related) clarifications
to the text about ENCRYPTED and HMAC calculation. Here's what we came up:

6.2.16  ENCRYPTED

  <ascii graphics here>

  The ENCRYPTED parameter encapsulates another TLV, the encrypted data,
  which is also in TLV format. Consequently, the first fields in the
  encapsulated parameter(s) are Type and Length, allowing the contents to
  be easily parsed after decryption.

  Both the ENCRYPTED parameter and the encapsulated TLV(s) MUST be padded.
  The padding needed for the ENCRYPTED parameter is referred as the
  "outer" padding. Correspondingly, the padding for the parameter(s)
  encapsulated within the ENCRYPTED parameter is referred as the "inner"
  padding.

  The inner padding follows exactly the rules of Section 6.2.1. The outer
  padding also follows the same rules but with an exception. Namely, some
  algorithms require that the data to be encrypted must be a multiple of
  the cipher algorithm block size. In this case, the outer padding MUST
  include extra padding, as specified by the encryption algorithm. The
  size of the extra padding is selected so that the the length of the
  ENCRYPTED is the minimum value that is both multiple of eight and the
  cipher block size. The encryption algorithm may specify padding bytes
  other than zero; for example, AES [AES] uses the PKCS5 padding scheme
  [PKCS5] (see section 6.1.1) where the remaining n bytes to fill the
  block each have the value n.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane