Subject: [Hipsec] HIP_TRANSFORM and NULL Encryption

From: Robert Moskowitz <[email-masked]>
Date: Mon, 10 May 2010 08:58:28 -0400

If no one can provide a compelling argument for the NULL cipher for 
HIP_TRANSFORM, I am pulling it.  Of course it makes sense for 
ESP_TRANSFORM, but not HIP_TRANSFORM.  The only argument I have come up 
with is for testing the HIP encryption process; but that seems very weak.

So if no one speaks up, it will be pulled from 5201-bis.

---

From: Tobias Heer <[email-masked]>
Date: Mon, 10 May 2010 15:02:51 +0200

Hi, 

Am 10.05.2010 um 14:58 schrieb Robert Moskowitz:

> If no one can provide a compelling argument for the NULL cipher for HIP_TRANSFORM, I am pulling it.  Of course it makes sense for ESP_TRANSFORM, but not HIP_TRANSFORM.  The only argument I have come up with is for testing the HIP encryption process; but that seems very weak.

I think it would only affect the HIP_ENCRYPTED part of the packet, right? This seems more like a debugging feature than something that we need in the protocol specs. I am fine with removing it.

Tobias

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

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 10 May 2010 09:08:16 -0400

> I think it would only affect the HIP_ENCRYPTED part of the packet, right? This seems more like a debugging feature than something that we need in the protocol specs. I am fine with removing it.

That is the only place I see it used. And I don't see that changing, 
perhaps more things in HIP_ENCRYPTED with plans for DIET HIP, but still 
only makes sense for testing.

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 10 May 2010 09:17:17 -0700

> >> If no one can provide a compelling argument for the NULL 
> cipher for HIP_TRANSFORM, I am pulling it.  Of course it 
> makes sense for ESP_TRANSFORM, but not HIP_TRANSFORM.  The 
> only argument I have come up with is for testing the HIP 
> encryption process; but that seems very weak.
> >>      
> > I think it would only affect the HIP_ENCRYPTED part of the 
> packet, right? This seems more like a debugging feature than 
> something that we need in the protocol specs. I am fine with 
> removing it.
> >    
> 

Yes, using NULL as the HIP_TRANSFORM seems useful only for debugging. One example use is for snooping the HIP_ENCRYPTED TLV using wireshark, so you can tell that the host identity is properly wrapped and padded. Another example would be testing crypto performance, you can use NULL as a baseline.

-Jeff

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 10 May 2010 15:22:15 -0400

> Yes, using NULL as the HIP_TRANSFORM seems useful only for debugging. One example use is for snooping the HIP_ENCRYPTED TLV using wireshark, so you can tell that the host identity is properly wrapp…

So you vote for leaving it in.  But are you OK with removing it from 
MANDITORY to implement?

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 10 May 2010 12:45:40 -0700

> > Yes, using NULL as the HIP_TRANSFORM seems useful only for 
> debugging. One example use is for snooping the HIP_ENCRYPTED 
> TLV using wireshark, so you can tell that the host identity 
> is properly wrapped and padded. Another example would be 
> testing crypto performance, you can use NULL as a baseline.
> >    
> 

I think it's OK to remove, or yes just leave it as optional. When performing such tests you would probably carefully configure each side of the association to use NULL.

-Jeff