Subject: [Hipsec] Fwd: [anonsec] draft-zhang-btns-icmp-sec-extension-01

From: Pekka Nikander <[email-masked]>
Date: Fri, 2 Mar 2007 10:43:16 +0200

Could someone from the HIP WG review this and see if HIP could be  
easily adopted to use these ICMP messages?

--Pekka Nikander

Begin forwarded message:

> From: "CTO ZHANG Qingshan" <[email-masked]>
> Date: 2 March 2007 04:58:33 GMT+02:00
> To: <[email-masked]>
> Cc: [email-masked]
> Subject: [anonsec] draft-zhang-btns-icmp-sec-extension-01
>
> Hi, dear all,
>
> With great help of Alfred and other members of the group, the 2nd  
> version of the I-D (Extension of ICMP Security Failures Messages)  
> has been finished. Great thanks to them! :-)
>
> Any comments from you are appreciated.
>
> Best regards,
> Qingshan
>
>
> _______________________________________________

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Andrew McGregor <[email-masked]>
Date: Sat, 3 Mar 2007 10:42:36 +1300

On a quick look at this and RFC 2521, which it extends, I'd say HIP  
certainly could use this idea.  Many of the codepoints defined are  
IPSEC specific, so use with HIP may require some extra codepoints.

In summary, the draft together with RFC 2521 defines a way to use  
ICMP to be more specific about the nature of an association failure  
than just 'Host unavailable, administratively denied', which is the  
ICMP message HIP currently uses.  Although this does leak some  
information, it is also potentially much more user-friendly.

Andrew

On 02/03/2007, at 9:43 PM, Pekka Nikander wrote:

>> <draft-zhang-btns-icpm-sec-extension-01.txt>

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 4 Mar 2007 16:50:31 +0200

So, would there be any point of suggesting some (experimental) HIP- 
specific code points for the draft?

--Pekka

---

From: Andrew McGregor <[email-masked]>
Date: Mon, 5 Mar 2007 11:38:13 +1300

I'll have a more detailed look; I haven't yet had a close look at  
2521, so I don't know yet.  My initial feeling is that existing  
codepoints look sufficient, and it's more a matter of defining HIP- 
specific semantics for  them.

Andrew

On 05/03/2007, at 3:50 AM, Pekka Nikander wrote:

>> On a quick look at this and RFC 2521, which it extends, I'd say  
>> HIP certainly could use this idea.  Many of the codepoints defined  
>> are IPSEC specific, so use with HIP may require some extra  
>> codepoints.
>>
>> ICMP to be more specific about the nature of an association  
>> failure than just 'Host unavailable, administratively denied',  
>> which is the ICMP message HIP currently uses.  Although this does  
>> leak some information, it is also potentially much more user- 
>> friendly.
>>
>> Andrew
>>
>>>> With great help of Alfred and other members of the group, the  
>>>> 2nd version of the I-D (Extension of ICMP Security Failures  
>>>> Messages) has been finished. Great thanks to them! :-)
>>>>

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 8 Mar 2007 13:28:18 +1300

So, I've done some more reading.

As I see it, there's a matter of design philosophy here.

What HIP is presently specified to do with ICMP errors is to generate  
an ICMP Parameter Problem message, pointing at the field that  
generated the error.  This is a simple and uniform way to indicate  
any of the problems that can occur, and is extensible.  Combined with  
the HIP Notification message, we appear to be able to indicate all  
the conditions necessary already.

2521 and draft-zhang-btns-icpm-sec-extension are another way to  
indicate these errors.  It appears somewhat simpler to process the  
messages defined in those, but at the same time the indications are  
less specific.

The design question is, at this late stage, is it worth making a  
change that loses some diagnostic functionality for the sake of  
uniformity with 2521 and btns?  Or, does the specificity of the  
Parameter Problem message really win anything?

Andrew

On 05/03/2007, at 11:38 AM, Andrew McGregor wrote:

>>> HIP certainly could use this idea.  Many of the codepoints  
>>> defined are IPSEC specific, so use with HIP may require some  
>>> extra codepoints.
>>>
>>>> Could someone from the HIP WG review this and see if HIP could  
>>>> be easily adopted to use these ICMP messages?
>>>>
>>>> --Pekka Nikander
>>>>
>>>>
>>>> Begin forwarded message:
>>>>

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 8 Mar 2007 10:20:54 +0200

Hmm.  Based on what you write, I think we don't need to do anything  
now.  But of course, it would be good to keep an eye on this and see  
later, based on some implementation and operational experience, what  
is the relative value of the approaches.

--Pekka

On 8 Mar 2007, at 02:28, Andrew McGregor wrote:

> What HIP is presently specified to do with ICMP errors is to  
> generate an ICMP Parameter Problem message, pointing at the field  
> that generated the error.  This is a simple and uniform way to  
> indicate any of the problems that can occur, and is extensible.   
> Combined with the HIP Notification message, we appear to be able to  
> indicate all the conditions necessary already.
>
>>> So, would there be any point of suggesting some (experimental)  
>>> HIP-specific code points for the draft?
>>>
>>> --Pekka
>>>
>>>> In summary, the draft together with RFC 2521 defines a way to  
>>>> use ICMP to be more specific about the nature of an association  
>>>> which is the ICMP message HIP currently uses.  Although this  
>>>> does leak some information, it is also potentially much more  
>>>> user-friendly.
>>>>
>>>> Andrew
>>>>