Subject: [Hipsec-rg] RG scheduling and agenda items
From: [email-masked] (Henderson, Thomas R)
Date: Fri Sep 30 10:30:00 2005

We are planning for another RG meeting in Vancouver.  In Paris, we were
not able to meet on the Friday PM slot due to the facilities.  In
Vancouver, I believe that we have that option again.  After discussing
with the IRTF chair, we decided that the opportunity to meet without
other IETF WG conflicts slightly favors a Friday PM meeting slot.
Therefore, unless there is a strong objection, I am planning to submit
the following request to the secretariat:

First slot preference:  Friday PM (2.5 hrs)
Second slot preference:  Friday AM (2.5 hrs)

If there are any comments or discussions on this point, please be aware
that we have until Oct 3, 2100 GMT to submit our request.

Please also consider this Friday scheduling in your travel plans.

Also, I am soliciting a request for agenda items.  Beyond Internet Draft
presentations of new or existing ideas (still strongly encouraged), and
updates on HIP-related research projects, I am planning that our RG
meeting also has time alloted for discussion of deployment issues,
reviews and discussion of new software updates and demonstrations, or
other issues that people want to bring forward. =20

The important meeting deadlines are posted at:
http://www.ietf.org/meetings/cutoff_dates_64.html

From: [email-masked] (Pekka Nikander)
Date: Thu Sep 15 05:57:00 2005
Subject: [Hipsec-rg] Fwd: CH and p2p
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I haven't really been following the details of the CH discussion at  
IETF-discuss, so I can't really state exactly.  However, what I think  
is wanted is an ability for any node to "call home" through various  
firewalls and middle boxes, independent on its location and the  
location of the "home".  Seems like a fairly good extension  
opportunity for HIP + RVS.

--Pekka

On Sep 15, 2005, at 11:42, Miao Fuyou wrote:

>
> Could you please shed more light on HIP-CH?  What Ned had given is too
> specific a scenario, I think.
>
> -Miao
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Pekka  
> Nikander
> Sent: Thursday, September 15, 2005 5:23 PM
> To: [email-masked]
> Subject: [Hipsec-rg] Fwd: CH and p2p
>
>
> Anyone interested in taking a challenge and work out how to implement
> Call Home (CH) with HIP, potentially introducing a new Service
> (utilising the Registration protocol) that may be co-located with the
> RVS Service?
>
> --Pekka
>
>
> Begin forwarded message:
>
>
>> From: Brian E Carpenter <[email-masked]>
>> Date: September 15, 2005 10:36:30 GMT+02:00
>> To: Michael Thomas <[email-masked]>
>> Cc: [email-masked], [email-masked], Ned Freed
>> <[email-masked]>, 'IETF Discussion' <[email-masked]>, 'Eliot
>> Lear' <[email-masked]>
>> Subject: CH and p2p [Re: [Isms] ISMS charter broken- onus should be
>> on WG to fix it]
>>
>>
>> If you want to discuss this as a generic issue, please do so
>> with an appropriate subject and without cross posting. Thanks.
>>
>> BTW I agree that there is a generic architectural issue here
>> that merits discussion.
>>
>>    Brian
>>
>>
>> Michael Thomas wrote:
>>
>>
>>> Ned Freed wrote:
>>>
>>>
>>>>> Ned Freed wrote:
>>>>>
>>>>>> If I were to object to Eliot's proposal (I don't - in fact I
>>>>>>
>>>>> strongly
>>>>>
>>>>>> support
>>>>>> it), it would be on the grounds that the IETF should be taking
>>>>>>
>>>>> a long
>>>>>
>>>>>> hard look
>>>>>> at the issues surrounding call home in general, not just in
>>>>>>
>>>>> the special
>>>>>
>>>>>> case of
>>>>>> SNMP.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I'll bite: what could the IETF do if it looked
>>>>> long and hard?
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> Well, the one approach that immediately comes to mind is that the
>>>> introduction
>>>> of a third party might provide a means of getting timely
>>>> information about
>>>> software updates without sacrificing user privacy.
>>>>
>>>> Such a third party would act as a repository for update
>>>> information provided by
>>>> vendors. Applications would then "call home" to one of these
>>>> repositories
>>>> rather than directly to the vendor. Various anonymyzing tricks
>>>> could be
>>>> employed to minimize information leakage even if the third party  
>>>> was
>>>> compromised.
>>>>
>>>>
>>> You mean we could invent Bitorrent? :)
>>>         Mike, doesn't it strike others as odd
>>>          that ietf is completely outside of the
>>>          p2p bizness?
>>>
>>>
>>
>>
>> _______________________________________________
>> Ietf mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ietf
>>
>>
>>
>
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
>
> _______________________________________________
> Hipsec-rg mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec-rg
>
>

From: [email-masked] (Miao Fuyou)
Date: Thu Sep 15 05:34:01 2005
Subject: [Hipsec-rg] Fwd: CH and p2p
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Could you please shed more light on HIP-CH?  What Ned had given is too
specific a scenario, I think.

-Miao

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pekka Nikander
Sent: Thursday, September 15, 2005 5:23 PM
To: [email-masked]
Subject: [Hipsec-rg] Fwd: CH and p2p

Anyone interested in taking a challenge and work out how to implement  
Call Home (CH) with HIP, potentially introducing a new Service  
(utilising the Registration protocol) that may be co-located with the  
RVS Service?

--Pekka

Begin forwarded message:

> From: Brian E Carpenter <[email-masked]>
> Date: September 15, 2005 10:36:30 GMT+02:00
> To: Michael Thomas <[email-masked]>
> Cc: [email-masked], [email-masked], Ned Freed
> <[email-masked]>, 'IETF Discussion' <[email-masked]>, 'Eliot  
> Lear' <[email-masked]>
> Subject: CH and p2p [Re: [Isms] ISMS charter broken- onus should be  
> on WG to fix it]
>
>
> If you want to discuss this as a generic issue, please do so
> with an appropriate subject and without cross posting. Thanks.
>
> BTW I agree that there is a generic architectural issue here
> that merits discussion.
>
>    Brian
>
>
> Michael Thomas wrote:
>
>> Ned Freed wrote:
>>
>>>> Ned Freed wrote:
>>>> > If I were to object to Eliot's proposal (I don't - in fact I  
>>>> strongly
>>>> > support
>>>> > it), it would be on the grounds that the IETF should be taking  
>>>> a long
>>>> > hard look
>>>> > at the issues surrounding call home in general, not just in  
>>>> the special
>>>> > case of
>>>> > SNMP.
>>>>
>>>
>>>
>>>
>>>
>>>> I'll bite: what could the IETF do if it looked
>>>> long and hard?
>>>>
>>>
>>>
>>>
>>> Well, the one approach that immediately comes to mind is that the  
>>> introduction
>>> of a third party might provide a means of getting timely  
>>> information about
>>> software updates without sacrificing user privacy.
>>>
>>> Such a third party would act as a repository for update  
>>> information provided by
>>> vendors. Applications would then "call home" to one of these  
>>> repositories
>>> rather than directly to the vendor. Various anonymyzing tricks  
>>> could be
>>> employed to minimize information leakage even if the third party was
>>> compromised.
>>>
>> You mean we could invent Bitorrent? :)
>>         Mike, doesn't it strike others as odd
>>          that ietf is completely outside of the
>>          p2p bizness?
>>
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
>
>

_______________________________________________
Hipsec-rg mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec-rg

From: [email-masked] (Pekka Nikander)
Date: Thu Sep 15 05:15:01 2005
Subject: [Hipsec-rg] Fwd: CH and p2p
References: <[email-masked]>
Message-ID: <[email-masked]>

Anyone interested in taking a challenge and work out how to implement  
Call Home (CH) with HIP, potentially introducing a new Service  
(utilising the Registration protocol) that may be co-located with the  
RVS Service?

--Pekka

Begin forwarded message:

> From: Brian E Carpenter <[email-masked]>
> Date: September 15, 2005 10:36:30 GMT+02:00
> To: Michael Thomas <[email-masked]>
> Cc: [email-masked], [email-masked], Ned Freed  
> <[email-masked]>, 'IETF Discussion' <[email-masked]>, 'Eliot  
> Lear' <[email-masked]>
> Subject: CH and p2p [Re: [Isms] ISMS charter broken- onus should be  
> on WG to fix it]
>
>
> If you want to discuss this as a generic issue, please do so
> with an appropriate subject and without cross posting. Thanks.
>
> BTW I agree that there is a generic architectural issue here
> that merits discussion.
>
>    Brian
>
>
> Michael Thomas wrote:
>
>> Ned Freed wrote:
>>
>>>> Ned Freed wrote:
>>>> > If I were to object to Eliot's proposal (I don't - in fact I  
>>>> strongly
>>>> > support
>>>> > it), it would be on the grounds that the IETF should be taking  
>>>> a long
>>>> > hard look
>>>> > at the issues surrounding call home in general, not just in  
>>>> the special
>>>> > case of
>>>> > SNMP.
>>>>
>>>
>>>
>>>
>>>
>>>> I'll bite: what could the IETF do if it looked
>>>> long and hard?
>>>>
>>>
>>>
>>>
>>> Well, the one approach that immediately comes to mind is that the  
>>> introduction
>>> of a third party might provide a means of getting timely  
>>> information about
>>> software updates without sacrificing user privacy.
>>>
>>> Such a third party would act as a repository for update  
>>> information provided by
>>> vendors. Applications would then "call home" to one of these  
>>> repositories
>>> rather than directly to the vendor. Various anonymyzing tricks  
>>> could be
>>> employed to minimize information leakage even if the third party was
>>> compromised.
>>>
>> You mean we could invent Bitorrent? :)
>>         Mike, doesn't it strike others as odd
>>          that ietf is completely outside of the
>>          p2p bizness?
>>
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
>
>

From: [email-masked] (Jari Arkko)
Date: Mon Sep  5 00:13:01 2005
Subject: [Hipsec-rg] Re: AW: Comments on draft-tschofenig-hiprg-hip-srtp-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Tschofenig, Hannes wrote:

>>(However, one could design also tighter integration for HIP and SIP,
>>perhaps in the same manner as MIKEY can be carried as an optimization
>>in the SIP negotiation so that you don't need another set of 
>>roundtrips
>>to establish keys for SRTP sessions.)
>>    
>>
>this might also be possible but i think hip does not provide this type
>of flexibility.
>  
>
Right.

>>Re: including MIKEY in the HIP base exchange. It looks like
>>the beginning of the document says this, but when I look
>>at Section 3.1 and 3.3 it looks more like direct implementation
>>of SRTP keying in the base exchange than carrying MIKEY.
>>Of course the parameters are similar, as can be expected.
>>    
>>
>
>the wording seems to need improvement. 
>
>if we want to establish a keying material and parameters for srtp then
>it was obvious to investigate what mikey did. as you said the parameters
>are similar. 
>  
>
Ok.

--Jari

From: [email-masked] (Tschofenig, Hannes)
Date: Sun Sep  4 18:20:01 2005
Subject: [Hipsec-rg] AW: Comments on draft-tschofenig-hiprg-hip-srtp-00.txt
Message-ID: <[email-masked]>

hi jari,

this document was produced in the context of our sip and hip
investigation (see draft-tschofenig-hiprg-host-identities-02.txt).=20

see my comments below:=20

> Pekka Nikander wrote:
>=20
> > I happened to have time to briefly review=20
> draft-tschofenig-hiprg-hip-=20
> > srtp-00.txt,
> > and here are my initial comments:
> >
> > General / High level:
> >
> > In general, I find the draft as a good start and a=20
> potentially good =20
> > approach.  However, I don't understand the relationship=20
> between SRTP =20
> > and MIKEY in detail enough to be able to really make any=20
> comments on =20
> > whether including MIKEY in the HIP base exchange is a good idea or =20
> > whether it would be better to derive SRTP keys directly from HIP =20
> > keymat.  My current estimate is, though, that it would be=20
> sufficient =20
> > to define how to derive the SRTP master key from the HIP=20
> keymat, and =20
> > drop MIKEY from the protocol.  AFAICT, that would be simpler.  Or =20
> > perhaps I just didn't understand the draft?  If MIKEY is=20
> not used (as =20
> > alluded in the introduction of the draft), why it is=20
> mentioned in the =20
> > first place.
> >
> > I found one aspect of the draft very confusing:  why does=20
> the draft =20
> > discuss SIP at all?  I find it very confusing.  The SRTP document =20
> > does not mention SIP at all, and I don't think it needs to be =20
> > mentioned in this document either.
>=20
> Re: SIP. I understood the SIP part of this document mainly as an=20
> illustration
> of a typical use case (perhaps that might be emphasized, maybe include
> the material as an appendix to make the core of the solution clearer).

you are right. there is no dependency on sip other that our
investigation started with the relationship between sip and hip and the
usage of srtp in combination with sip (when keying material is
established using mikey/sdp/sip signaling).=20
=20

>=20
> (However, one could design also tighter integration for HIP and SIP,
> perhaps in the same manner as MIKEY can be carried as an optimization
> in the SIP negotiation so that you don't need another set of=20
> roundtrips
> to establish keys for SRTP sessions.)
this might also be possible but i think hip does not provide this type
of flexibility.=20

>=20
> Re: including MIKEY in the HIP base exchange. It looks like
> the beginning of the document says this, but when I look
> at Section 3.1 and 3.3 it looks more like direct implementation
> of SRTP keying in the base exchange than carrying MIKEY.
> Of course the parameters are similar, as can be expected.

the wording seems to need improvement.=20

if we want to establish a keying material and parameters for srtp then
it was obvious to investigate what mikey did. as you said the parameters
are similar.=20

ciao
hannes

>=20
> --Jari
>=20
>=20
>=20

From: [email-masked] (Jari Arkko)
Date: Sat Sep  3 14:36:01 2005
Subject: [Hipsec-rg] Re: Comments on draft-tschofenig-hiprg-hip-srtp-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pekka Nikander wrote:

> I happened to have time to briefly review draft-tschofenig-hiprg-hip- 
> srtp-00.txt,
> and here are my initial comments:
>
> General / High level:
>
> In general, I find the draft as a good start and a potentially good  
> approach.  However, I don't understand the relationship between SRTP  
> and MIKEY in detail enough to be able to really make any comments on  
> whether including MIKEY in the HIP base exchange is a good idea or  
> whether it would be better to derive SRTP keys directly from HIP  
> keymat.  My current estimate is, though, that it would be sufficient  
> to define how to derive the SRTP master key from the HIP keymat, and  
> drop MIKEY from the protocol.  AFAICT, that would be simpler.  Or  
> perhaps I just didn't understand the draft?  If MIKEY is not used (as  
> alluded in the introduction of the draft), why it is mentioned in the  
> first place.
>
> I found one aspect of the draft very confusing:  why does the draft  
> discuss SIP at all?  I find it very confusing.  The SRTP document  
> does not mention SIP at all, and I don't think it needs to be  
> mentioned in this document either.

Re: SIP. I understood the SIP part of this document mainly as an 
illustration
of a typical use case (perhaps that might be emphasized, maybe include
the material as an appendix to make the core of the solution clearer).

(However, one could design also tighter integration for HIP and SIP,
perhaps in the same manner as MIKEY can be carried as an optimization
in the SIP negotiation so that you don't need another set of roundtrips
to establish keys for SRTP sessions.)

Re: including MIKEY in the HIP base exchange. It looks like
the beginning of the document says this, but when I look
at Section 3.1 and 3.3 it looks more like direct implementation
of SRTP keying in the base exchange than carrying MIKEY.
Of course the parameters are similar, as can be expected.

--Jari

From: [email-masked] (Pekka Nikander)
Date: Fri Sep  2 05:02:01 2005
Subject: [Hipsec-rg] Comments on draft-tschofenig-hiprg-hip-srtp-00.txt
Message-ID: <[email-masked]>

I happened to have time to briefly review draft-tschofenig-hiprg-hip- 
srtp-00.txt,
and here are my initial comments:

General / High level:

In general, I find the draft as a good start and a potentially good  
approach.  However, I don't understand the relationship between SRTP  
and MIKEY in detail enough to be able to really make any comments on  
whether including MIKEY in the HIP base exchange is a good idea or  
whether it would be better to derive SRTP keys directly from HIP  
keymat.  My current estimate is, though, that it would be sufficient  
to define how to derive the SRTP master key from the HIP keymat, and  
drop MIKEY from the protocol.  AFAICT, that would be simpler.  Or  
perhaps I just didn't understand the draft?  If MIKEY is not used (as  
alluded in the introduction of the draft), why it is mentioned in the  
first place.

I found one aspect of the draft very confusing:  why does the draft  
discuss SIP at all?  I find it very confusing.  The SRTP document  
does not mention SIP at all, and I don't think it needs to be  
mentioned in this document either.

Anyway, I am looking forward to the next version of the draft, which  
will hopefully be easier to read so that even my small brains can  
understand it.

Semi-substantial:

Should the document discuss more the changes to RFC3711 3.2.3, i.e.  
using the HIT instead of destination IP address in demultiplexing?   
That is mentioned, but IMO would warrant some more explanation; right  
now the statement is hard to understand.  At minimum, the  
abbreviation SSRC should be opened and briefly discussed.

I don't understand why the MKI must be negotiated?  Can't that be  
made implicit or at least optional?

I don't understand the rationale for the Master Salt either; AFAICT,  
that is not mentioned in RFC3711 Section 8.  OTOH, in Section 8 it is  
mentioned that the KMP must provide SSRC and may give the initial RTP  
sequence number.  I don't see these taken care of, but maybe I just  
don't understand the draft.

Detail:

The Introduction is somewhat convoluted, repeating the same issues in  
many paragraphs, with just slightly different words.  Simplification  
would be in place.

Section 3 requires much more introductory material on SRTP.  RFC3711  
is sufficiently confusing that it is hard to tell if the details of  
Section 3.3 are right.  In particular, if I compare the table on page  
36 of RFC3711 with the KEYING parameter contents on page 11 of the  
draft, I can't figure out how they match.

RFC3711 should definitely be normative reference, and RFC3830  
probably, too.  Alternatively, I thin,k RFC3830 should be removed if  
MIKEY need not be concerned.

I'd drop I-D.ietf-hip-sip and RFC3261 altogether from references, at  
the same time the discussion about SIP is removed.

--Pekka