Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Tue, 30 Sep 2008 16:11:37 -0700

Jan,

I have a few follow-ups below on your observations.

> -----Original Message-----
> From: Jan Mikael Melen [mailto:Jan.Melen at nomadiclab.com] 
> Sent: Tuesday, September 30, 2008 1:46 PM
> To: Tobias Heer
> Cc: hipsec-rg at honor.trusecure.com; Henderson, Thomas R
> Subject: Re: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
> 
> Hi Tobias,
> 
> I think that no one can give you a definitive answer whether 
> HIP aware 
> middleboxes will ever exist or not. The thing is that it is really 
> dependent on the fact whether HIP ever gets deployed in large 
> scale or 
> not? 

(co-chair hat off)

I do not think that HIP-aware middleboxes are on the critical path to
deploying HIP, so I can't personally prioritize spending cycles on it,
at this time, over working on the NAT traversal draft or on
implementations or other deployment-related things.

That being said, I have heard of some interest in being able to use HIP
to support security use cases where there is path-coupled signaling for
authentication, for certain security-conscious environments.  This
includes interest from within my own company.  A competing architecture,
however, is OpenFlow/Ethane, which operates at L2 and arguably provides
more security.

> I personally am still betting on the fact that HIP will 
> eventually 
> be deployed due to fact that it still has a lot of good 
> features nicely 
> packaged into a single protocol so from that perspective I do support 
> the work you are doing. 
> It even seems that a lot of people in 
> the IETF 
> are looking into HIP and HIP kind of solutions. In the last 
> IETF I heard 
> HIP mentioned several times but still in the same comments 
> there was a 
> lot of hesitation on the deployment issue. 

To me, there seems to be continual and renewable interest in finding one
or more names to use as stable identifiers above the forwarding layer in
the architecture, but there never is a convergence on what this name (or
names) should be, or the degree of transparency/exposure to
applications.  I think that if you explain HIP to people, they
immediately get the concept, but there are so many variations possible,
and tradeoffs among them, and even disagreement on the problems or
priorities being addressed, that it is hard to agree on a unifying
solution.

> But as you 
> probably have also 
> noted from the previous meetings, the HIP-RG and WG discussion are 
> really dead and we really must find a user for HIP (meaning 
> new people 
> in to RG and WG meetings) otherwise I think that the 
> collaboration you 
> are expecting is not going to be as fruitful as you would 
> like it to be.

I agree with this comment; I think that this draft (or any other
feature) needs to find use cases and deployment scenarios to spark some
interest and urgency from possible users.  I think that Tobias has
outlined a few such cases, but there needs to be some pull from users
who want to architect security in this manner.

> 
> Btw. Latest twist on the ID/Loc issue began from Dublin where 
> in the RRG 
> meeting during the Joe Halperns Id/Loc split presentation a 
> question was 
> raised why not push down the FQDN in to the stack. This is 
> not really a 
> new idea but first time I've heard some serious discussion on 
> the topic 
> if you want to know more go and see the mailing archive of RRG.

Along these lines (of using FQDN as the stable identifier), I would
recommend to read over the slides from Dave Thaler's Mobiarch keynote,
available at:
http://conferences.sigcomm.org/sigcomm/2008/workshops/mobiarch/

- Tom

From: Jan.Melen at nomadiclab.com (Jan Mikael Melen)
Date: Tue, 30 Sep 2008 23:45:40 +0300
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Tobias,

I think that no one can give you a definitive answer whether HIP aware 
middleboxes will ever exist or not. The thing is that it is really 
dependent on the fact whether HIP ever gets deployed in large scale or 
not? I personally am still betting on the fact that HIP will eventually 
be deployed due to fact that it still has a lot of good features nicely 
packaged into a single protocol so from that perspective I do support 
the work you are doing. It even seems that a lot of people in the IETF 
are looking into HIP and HIP kind of solutions. In the last IETF I heard 
HIP mentioned several times but still in the same comments there was a 
lot of hesitation on the deployment issue. But as you probably have also 
noted from the previous meetings, the HIP-RG and WG discussion are 
really dead and we really must find a user for HIP (meaning new people 
in to RG and WG meetings) otherwise I think that the collaboration you 
are expecting is not going to be as fruitful as you would like it to be.

Btw. Latest twist on the ID/Loc issue began from Dublin where in the RRG 
meeting during the Joe Halperns Id/Loc split presentation a question was 
raised why not push down the FQDN in to the stack. This is not really a 
new idea but first time I've heard some serious discussion on the topic 
if you want to know more go and see the mailing archive of RRG.

Just my few cents,
    Jan

Tobias Heer wrote:
> Hello Thomas,
>
> Thanks for raising the discussion again. I am of course willing to 
> continue to work on the draft in any way. However, I would prefer to 
> continue in close collaboration with the RG or the WG as their input 
> means a lot to me.
>
> I guess the question whether to pursue the draft is essentially the 
> question if HIP should be used for path-coupled signaling to 
> middleboxes (i.e., expect that at some point in time there will be 
> middleboxes that inspect HIP payload and use the HI namespace). 
> Therefore, I would be interested if the RG thinks that using the HI 
> namespace by on-path HIP-aware nodes is useful/desired/necessary or 
> not. If so, is the approach that the draft takes a good one or should 
> we reconsider?
>
> Input from the list is very appreciated.
>
> Thanks in advance,
>
> Tobias
>
>
>
>
>
>
> Am 03.09.2008 um 17:56 schrieb Henderson, Thomas R:
>
>> I'd like to solicit some comments on
>> http://tools.ietf.org/id/draft-heer-hip-middle-auth-01.txt
>>
>> Tobias has presented this draft a couple of times now, and at the end of
>> the last RG meeting was asking whether the HIPRG wanted to continue to
>> work on this topic.
>>
>> There was some discussion of this draft in January in which Julien asked
>> for clarification of what security service we want to provide, and what
>> are the requirements being addressed, since it was pointed out that
>> authentication of the base exchange was not carrying over to the ESP
>> data flows.  Section 4 of the updated draft responds to this request.
>>
>> As a matter of procedure, there are a few directions the RG can take
>> with respect to this or any draft within scope of our charter:
>> 1) agree to take on the draft as a RG item and try to publish it as a RG
>> draft, according to the process being defined in
>> http://tools.ietf.org/id/draft-irtf-rfcs-01.txt
>> 2) recommend to the HIP WG that they take the draft
>> 3) decline to take the draft and recommend to the authors to publish it
>> as an independent submission
>>
>> If we agree to 1), we will need to come to some RG consensus on the
>> draft and willingness to work on it through the publication process.
>>
>> Comments?
>>
>> Tom
>> _______________________________________________
>> Hipsec-rg mailing list
>> Hipsec-rg at listserv.cybertrust.com
>> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>
>
>
>
> -- Dipl.-Inform. Tobias Heer, Ph.D. Student
> Distributed Systems Group
> RWTH Aachen University, Germany
> http://ds.cs.rwth-aachen.de/members/heer
>
>
>
>
>
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg
>
>

From: miika.komu at hiit.fi (Miika Komu)
Date: Sat, 27 Sep 2008 00:53:35 +0300
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Joakim Koskela wrote:

Hi,

> On Wednesday 24 September 2008 12:43:21 Ren? Hummen wrote:
>> Hi,
>>
>>> As a matter of procedure, there are a few directions the RG can take
>>> with respect to this or any draft within scope of our charter:
>>> 1) agree to take on the draft as a RG item and try to publish it as a RG
>>> draft, according to the process being defined in
>>> http://tools.ietf.org/id/draft-irtf-rfcs-01.txt
>>> 2) recommend to the HIP WG that they take the draft
>>> 3) decline to take the draft and recommend to the authors to publish it
>>> as an independent submission
>>>
>>> If we agree to 1), we will need to come to some RG consensus on the
>>> draft and willingness to work on it through the publication process.
>>>
>>> Comments?
>> I recommend it as a WG draft as the security enhancements described in
>> there are necessary for providing secure middlebox functions like the HIP
>> relay, which e.g. is used in the NAT traversal draft.
>>
> 
> Hi,
> 
> +1 for the same reasons.

as a co-author of the draft, I tend to be biased but +1 for me too.

From: heer at cs.rwth-aachen.de (Tobias Heer)
Date: Thu, 25 Sep 2008 16:14:50 +0200
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello Thomas,

Thanks for raising the discussion again. I am of course willing to  
continue to work on the draft in any way. However, I would prefer to  
continue in close collaboration with the RG or the WG as their input  
means a lot to me.

I guess the question whether to pursue the draft is essentially the  
question if HIP should be used for path-coupled signaling to  
middleboxes (i.e., expect that at some point in time there will be  
middleboxes that inspect HIP payload and use the HI namespace).  
Therefore, I would be interested if the RG thinks that using the HI  
namespace by on-path HIP-aware nodes is useful/desired/necessary or  
not. If so, is the approach that the draft takes a good one or should  
we reconsider?

Input from the list is very appreciated.

Thanks in advance,

Tobias

Am 03.09.2008 um 17:56 schrieb Henderson, Thomas R:

> I'd like to solicit some comments on
> http://tools.ietf.org/id/draft-heer-hip-middle-auth-01.txt
>
> Tobias has presented this draft a couple of times now, and at the  
> end of
> the last RG meeting was asking whether the HIPRG wanted to continue to
> work on this topic.
>
> There was some discussion of this draft in January in which Julien  
> asked
> for clarification of what security service we want to provide, and  
> what
> are the requirements being addressed, since it was pointed out that
> authentication of the base exchange was not carrying over to the ESP
> data flows.  Section 4 of the updated draft responds to this request.
>
> As a matter of procedure, there are a few directions the RG can take
> with respect to this or any draft within scope of our charter:
> 1) agree to take on the draft as a RG item and try to publish it as  
> a RG
> draft, according to the process being defined in
> http://tools.ietf.org/id/draft-irtf-rfcs-01.txt
> 2) recommend to the HIP WG that they take the draft
> 3) decline to take the draft and recommend to the authors to publish  
> it
> as an independent submission
>
> If we agree to 1), we will need to come to some RG consensus on the
> draft and willingness to work on it through the publication process.
>
> Comments?
>
> Tom
> _______________________________________________
> Hipsec-rg mailing list
> Hipsec-rg at listserv.cybertrust.com
> https://listserv.cybertrust.com/mailman/listinfo/hipsec-rg

--  
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group
RWTH Aachen University, Germany
http://ds.cs.rwth-aachen.de/members/heer

From: samu.varjonen at helsinki.fi (Varjonen Samu)
Date: Thu, 25 Sep 2008 16:07:59 +0300
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Sorry this took so long but I had "few" comments :)

Joakim Koskela wrote:
 > On Wednesday 24 September 2008 12:43:21 Ren? Hummen wrote:
 >> Hi,
 >>
 >>> As a matter of procedure, there are a few directions the RG can take
 >>> with respect to this or any draft within scope of our charter:
 >>> 1) agree to take on the draft as a RG item and try to publish it as 
a RG
 >>> draft, according to the process being defined in
 >>> http://tools.ietf.org/id/draft-irtf-rfcs-01.txt
 >>> 2) recommend to the HIP WG that they take the draft
 >>> 3) decline to take the draft and recommend to the authors to publish it
 >>> as an independent submission
 >>>
 >>> If we agree to 1), we will need to come to some RG consensus on the
 >>> draft and willingness to work on it through the publication process.
 >>>
 >>> Comments?
 >> I recommend it as a WG draft as the security enhancements described in
 >> there are necessary for providing secure middlebox functions like 
the HIP
 >> relay, which e.g. is used in the NAT traversal draft.
 >>
 >
 > Hi,
 >
 > +1 for the same reasons.
 >
 > br,
 > Joakim Koskela

Ok here are the comments, some might sound like nitpicks but in my 
opinion they make the draft more readable/understandable and some of the 
  comments overlap each other in various degrees.

1. References to BASE, ESP, MM ... have to be changed to RFCs as we have 
them.

2. In Abstract HIP is referenced to RFC2119 which is the usage of 
keywords RFC

3. Section 1.1. third paragraph in the middle ""fake" ESP packets with 
valid ESP numbers" probably should be SPI numbers

4. Section 2.1. end of second paragraph. "end-hosts sign with public-key 
(PK) signatures". Would it be better if it was "end-hosts integrity 
protect with PK signatures". Because I do not sign with a signature I 
sign with my private-key.

5. Next paragraph, "The middlebox adds an ECHO_REQUEST_M
    parameter to the first HIP control packet that contains a nonce". 
This was probably meant as "The middlebox add an E_RQ_M to the first HIP 
control packet that contains a D-H nonce.". Hmm, why not just say R1 
control packet?

6. Section 2.1.1. "E_RQ_M parameters to the the R1, I2 and to any UPDATE 
packet". First there is a double "the". Secondly, for example in the 
UPDATE procedure (3-way) using E_RQ_M in the last UDPATE would result 
into extra UPDATE just for the middlebox. The other end would not know 
what to do with the UPDATE, mbox could just drop the UPDATE and not send 
it through if it is just an extra UPDATE with E_R_M with no other 
content. This is relevant also to 2.1.3. first paragraph and 2.2.2. 
RESPONSE RULE mentions this extra packet also. In cases where there is 
three packets, like mobility, so why add it to the last, you can but 
there is no point. Should it be clarified that instead of any UDPATE 
that E_RQ_M/P_M would be inserted into the first UPDATE going to proper 
directions according to which is authenticated, Initiator or Responder.

7. 2.1.1. first paragraph "maximum of 32 bytes". Where does this limit 
come? it should be mentioned also/or in the parameter definition 2.5.1.

8. Reference to R'FC2460 for the 1280 minimum MTU for IPv6 section 2.1.1. 
first paragraph.

9. section 2.1.1. end of second paragraph "MAY also rewrite the 
ECHO_REQUEST_UNSIGNED parameter as specified in [I-D.ietf-hip-base]" 
this is written in RFC 5201 like " It is possible that middleboxes add 
ECHO_REQUEST_UNSIGNED parameters in HIP packets passing by". If I read 
this I understand it like this, the middlebox ADDS E_RQ_UNSIGNED to the 
packets and does not rewrite/modify existing parameters. Clarification 
what is meant, please.

10. Next paragraph, request comes before response, so the they 
(parameters) should be listed in such order. Matter of opinion and mine 
is that they should be listed in order of use.

11. Section 2.1.2. first paragraph, middlebox expects to see E_R_M to 
E_RQ_M in subsequent packet. I understand this like, middlebox expects 
to see E_R_M in some following packet. I think it should say in the next 
control packet. Because middlebox may drop the traffic when E_RQ_M is 
missing.

12. All the parameters could be combined into two parameters, like I 
have presented in earlier mails commenting this draft sent to this list. 
Was there some reason why this is not done? I do not remember this been 
explained. If the decision is to keep two parameters (request/response 
and puzzle/solution as separate parameters) then why not remove the 
opaque from the puzzle. It is mentioned as inadequate in some 
situations, so why not use the request/response pair always when needed 
and not the opaque in puzzle/solution.

13. 2.1.3. second paragraph "must solve", should this be "MUST solve" 
because if you do not you might face a stop to your traffic

14. Next paragraph, how does the middlebox notice it is under attack or 
just under heavy load. Puzzle could also be used as a load "alleviating" 
solution where it could slow the creation of new connections and hoping 
that in the time it takes to solve the puzzle someone goes away and 
gives the bandwidth to the new one. This might be just a mindfart :)

15. Figure numbering Starts from 2 and text starts from fig 1 and some 
of the references to figs seem to be out of sync with the numbering of 
the figs. Check all of them because some seem to point correctly and 
others not.

16. It would be cleaner and easier to read if the labels of fig where 
like this "Figure 2: Middlebox authentication of a HIP BEX" and not the 
way it is now, "figure 2" below fig and explanation on top of fig.

17. Section 2.2.2. it says NATted environments are left to future 
revisions of this draft. Should it be explained in the NAT draft 
instead. At least on the list it is said that this draft is already used 
in the NAT draft... see start of this mail.

18. 2.2.2. end of second paragraph "in figure 3 I)" is the "I)" a left 
over from earlier versions or does it point to the two middlebox fig?

19. Clearly separate the RULE from other text.

20. Hey, now it says that with updates the E_RQ_M must be in the next 
packet see this mail 11.

21. 2.2.2. reference to a fig when mentioning middlebox 1. There is two 
figs with middlebox 1. Why the other one says middlebox 1 there is no 
other middleboxes so it could be just middlebox.

22. 2.2.2. second to last paragraph, how does the middlebox know if 
something is missing if it has not seen U1 message.

23. 2.2.2. last paragraph seems like repetition mentioned already in 
2.1.2. last paragraph.

24. 2.2.3. "Figure 4 I) and II)". I) is a repetition of the last fig. Or 
is the last fig unnecessary... Move II) to later where the text talks 
about middlebox 2.

25. in fig 4 (currently) II) U1 passes the middlebox 2 is this a case 
where the U1 is UPDATE LOCATOR with one locator with preferred bit set 
leading to U2 coming through different route or is this something 
related to asymmetric routes which usage, to my knowledge, is not defined?

26. Fig 4. (currently) in the second last packet ER1, ans SM1 resurface 
when they should be ER4 and SM4.

27. 2.2.4. Is it not sufficient to say that use HOST_ID always when the 
locator pair is unused?
With BEX HOST_IDs are already in the packets and with UPDATE only 
relevant case is the mobility update, covered by "unused locators" 
sentence. Otherwise we know the HI already. I cannot figure a case where 
you could not know HIs without the changing locators. Clarification to 
the why.

28. 2.3. "sender of BEX" ... sender?. It is initiator if only initiator 
is authenticated and responder if responder is autenticated or both.

28. 2.3. Other reasons should be covered somehow. Because it can be that 
credentials delivered by CERT parameter are not sufficient... so, other 
reasons depending on the policies of the middlebox maintainers can lead 
to failure signaling and it should be mentioned.

29. In the parameters 2.5.1. and 2.5.2. explain more clearly the length 
of the opaque data. Currently it needs to be len mod 32 == 0 bits 
otherwise padding is needed. Only related value to the length is the 32 
byte maximum mentioned far away in 2.1.1.

30. 4.1.1. End of the first paragraph, in the current version attacker 
is able to replay closing of the channel, because it is stated that its 
protection is future work.

31. 5. second paragraph, responder can send the puzzle to the initiator 
as I have shown in earlier mails commenting this draft. But it results 
into more packets sent on the wire.

Keep up the good work, I support this work :) Reasons are the same as 
stated in the earlier mails from Rene and Joakim...

BR,
Samu Varjonen

From: joakim.koskela at hiit.fi (Joakim Koskela)
Date: Wed, 24 Sep 2008 13:32:26 +0300
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wednesday 24 September 2008 12:43:21 Ren? Hummen wrote:
> Hi,
>
> >As a matter of procedure, there are a few directions the RG can take
> >with respect to this or any draft within scope of our charter:
> >1) agree to take on the draft as a RG item and try to publish it as a RG
> >draft, according to the process being defined in
> >http://tools.ietf.org/id/draft-irtf-rfcs-01.txt
> >2) recommend to the HIP WG that they take the draft
> >3) decline to take the draft and recommend to the authors to publish it
> >as an independent submission
> >
> >If we agree to 1), we will need to come to some RG consensus on the
> >draft and willingness to work on it through the publication process.
> >
> >Comments?
>
> I recommend it as a WG draft as the security enhancements described in
> there are necessary for providing secure middlebox functions like the HIP
> relay, which e.g. is used in the NAT traversal draft.
>

Hi,

+1 for the same reasons.

br,
Joakim Koskela

From: Rene.Hummen at rwth-aachen.de (=?iso-8859-1?Q?=22Ren=E9_Hummen=22?=)
Date: Wed, 24 Sep 2008 12:43:21 +0300
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
Message-ID: <[email-masked]>

Hi,

>As a matter of procedure, there are a few directions the RG can take
>with respect to this or any draft within scope of our charter:
>1) agree to take on the draft as a RG item and try to publish it as a RG
>draft, according to the process being defined in
>http://tools.ietf.org/id/draft-irtf-rfcs-01.txt
>2) recommend to the HIP WG that they take the draft
>3) decline to take the draft and recommend to the authors to publish it
>as an independent submission
>
>If we agree to 1), we will need to come to some RG consensus on the
>draft and willingness to work on it through the publication process.
>
>Comments?

I recommend it as a WG draft as the security enhancements described in there are necessary for providing secure middlebox functions like the HIP relay, which e.g. is used in the NAT traversal draft.

Ren?

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Wed, 3 Sep 2008 08:56:06 -0700
Subject: [Hipsec-rg] comments on draft-heer-hip-middle-auth-01
Message-ID: <[email-masked]>

I'd like to solicit some comments on 
http://tools.ietf.org/id/draft-heer-hip-middle-auth-01.txt

Tobias has presented this draft a couple of times now, and at the end of
the last RG meeting was asking whether the HIPRG wanted to continue to
work on this topic.

There was some discussion of this draft in January in which Julien asked
for clarification of what security service we want to provide, and what
are the requirements being addressed, since it was pointed out that
authentication of the base exchange was not carrying over to the ESP
data flows.  Section 4 of the updated draft responds to this request.

As a matter of procedure, there are a few directions the RG can take
with respect to this or any draft within scope of our charter:
1) agree to take on the draft as a RG item and try to publish it as a RG
draft, according to the process being defined in
http://tools.ietf.org/id/draft-irtf-rfcs-01.txt
2) recommend to the HIP WG that they take the draft
3) decline to take the draft and recommend to the authors to publish it
as an independent submission

If we agree to 1), we will need to come to some RG consensus on the
draft and willingness to work on it through the publication process.

Comments?

Tom

From: thomas.r.henderson at boeing.com (Henderson, Thomas R)
Date: Tue, 2 Sep 2008 21:35:13 -0700
Subject: [Hipsec-rg] IETF 72 meeting minutes
Message-ID: <[email-masked]>

All,
I reconstructed some meeting minutes from the HIPRG session audio at
IETF 72:
http://www.ietf.org/proceedings/08jul/minutes/HIPRG.txt

Please email me with any corrections or extensions prior to Sept. 17
deadline.

We ought to have some list discussion on a few points raised at the
meeting, so I'll try to start those with separate threads.

- Tom