Subject: [Hipsec] IESG evaluation of base, esp, rvs, registration, and mm

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Apr 2007 22:53:53 +0300

Hi,

FYI: the IESG evaluations of the HIP drafts that are under review are 
available at the ID tracker.

Cheers,

Gonzalo

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

---

From: Julien Laganier <[email-masked]>
Date: Fri, 20 Apr 2007 14:56:15 +0200

Sam, Russ, HIP folks,

Please find below are some comments/questions on the 
IESG evaluation of the HIP document set:

> DISCUSSES AND COMMENTS: ====================== 
>
> Sam Hartman: 
> 
> Discuss [2007-04-18]: Hi. I've evaluated this
> document set and held it to a higher level of quality
> than I would normally hold an experimental
> publication to. I'm assuming there is some reasonable
> chance that this will be the basis of important
> internet architecture. I'd rather identify issues now
> than when a successor to this version of HIP goes to
> proposed. As such, many of my issues may be handled
> by documenting (in an IESG note?) as things that must
> be fixed before going to proposed.         

[...]
  
> HIP's handling of lost state seems insufficient to
> guarantee interoperability. Section 6.16 allows a HIP
> node to drop state at any time. However there is no
> mandatory to implement mechanism to recover other
> than waiting for a potentially very long timeout.
> Implementations MAY send ICMP messages;
> implementations may respond to these messages. But
> there is not actually a mechanism that people have to
> make available to solve this.        

I believe Section 6.16. is a left-over from pre 
CLOSE/CLOSE_ACK handshake times (See version -00, 
Section 8.9) since the problem Sam is describing is 
IIRC what made Erik Nordmark comes with the 
CLOSE/CLOSE_ACK handshake, and led us to integrate it 
in the protocol.

Section 6.16 should simply be deleted, IMHO.
 
[...]
 
> Section 6.2 of the base spec says that the IP address 
> a packet arrives/is sent on should be ignored. The 
> problem with this approach is that different 
> interfaces have different security properties. I may 
> well be willing to send data without confidentiality 
> protection over a interface internal to a corporation 
> but not over an external interface. This interaction 
> would need to be carefully explored and reasonable 
> controls added before HIP would be appropriate as a 
> standard. Thinking about HIP interacts with mandatory 
> access control in the SPD is also going to be 
> challenging. I discuss one case of this below.           

I understand Sam's point about willingness to *send* 
non-confidentiality protected over internal vs. 
external interfaces. 

But I miss the link with Section 6.2. which describes 
"Processing *Incoming* Application Data"...

So is the problem with *receiving* non-confidentiality 
protected traffic over an "untrusted" interface?

[...]

> In the ESP document , how does HIP interact with the
> SPD? Suppose I have an SPD entry saying that traffic
> to 18/8 needs to be protected. Suppose that I contact
> a machine via HIP whose HIT happens to resolve to
> something in 18/8. Do I expect double encapsulation?    

HITs are now ORCHIDs (see draft-laganier-ipv6-khi), 
i.e. a special type of IPv6 address which begin with 
prefix 2001:10::/28 (allocated in the IPv6 address 
space for ORCHIDs).

Because of that, the HIT-is-an-IP-in-SPD situation 
described above cannot happen.

I'm now thinking that since now HITs are IP addresses, 
we may just use the IPsec SPD to specify:

from 2001:10::/28 to 2001:10::/28 -> protect
from 2001:10::/28 to ^(2001:10::/28) -> block

In addition, we might want a flag for corresponding PAD 
entries similar to what BTNS does (BTNS_OK), e.g. 
HIP_OK.

> The ESP document does not make it clear what ipsec
> mode is being used. It sounds like beet is desired,
> but beet is not a normative reference. How is the
> mode indicated and what is the mandatory to implement
> mode?    

To me BEET looks pretty much like transport mode 
followed by NAT HIT->IP on the sending side, and vice 
versa (NAT followed by transport mode) on receiving 
side. Maybe we can specify that instead of BEET?
 
[...]

> Russ Housley:
> 
> Comment [2007-04-19]:
> 
> It is possible to run vanilla IPsec and HIP on the 
> same node and get the intended security services 
> applied to the intended traffic if one is careful 
> about configuration. The security services are 
> present, and it appears to be possible to use a 
> HIP-unaware IPsec to do the HIP ESP processing. One 
> should worry about whether there is a possibility of 
> a HIT conflicting with an actual IPv6 address as the 
> technique advocated for a HIP-unaware IPsec 
> implementation apparently has HITs masquerade as IPv6 
> addresses for IPsec processing.          

See my comments above about HITs now being special type 
of IPv6 addresses (so called ORCHIDs), thus making 
such conflicts no longer conflicts.
 
> Since HIP and IPsec share a common SPI space, and
> traffic on any HIP SPI completely bypasses IPsec
> policy. (Think about Steve Kent's usual rant about
> IPsec being more than just a means to apply
> cryptographic security mechanisms to traffic.) The
> assurances that IPsec provides are easily broken with
> HIP, since inbound HIP traffic bypasses the IPsec SPD
> and gets handed directly to HIP, which logically has
> its own SPD.        

See my comment above on introducing HIP SPD entries 
with ORCHIDs as selectors, and a HIP_OK PAD entry so 
that HIP traffic no longer bypasses IPsec, but is in 
fact IPsec, with a different key management protocol 
(HIP).

> It is not clear to me exactly how to avoid this
> situation, or what to add to the document to warn 
> about this security consideration. A long discussion
> may be needed. Since the document is intended for
> Experimental RFC, this may be an acceptable
> situation, but this must be resolved for this
> document to transition to the standards track.      

Do you think specifying IPsec PAD and SPD entries for 
HIP would solve these issues?

[...]

Thanks.

-- julien

---

From: Russ Housley <[email-masked]>
Date: Fri, 20 Apr 2007 16:58:37 -0400

>HIP would solve these issues?

Not sure.  This is the question that should be answered with 
implementation experience.  I hope people try to use HIP on the same 
host as vanilla IPsec so that we do learn the answer during the HIP experiment.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Tue, 24 Apr 2007 20:47:06 -0400

>>>>> "Julien" == Julien Laganier <[email-masked]> writes:

    Julien> Sam, Russ, HIP folks, Please find below are some
    Julien> comments/questions on the IESG evaluation of the HIP
    Julien> document set:

    >> Discuss [2007-04-18]: Hi. I've evaluated this document set and
    >> held it to a higher level of quality than I would normally hold
    >> an experimental publication to. I'm assuming there is some
    >> reasonable chance that this will be the basis of important
    >> internet architecture. I'd rather identify issues now than when
    >> a successor to this version of HIP goes to proposed. As such,
    >> many of my issues may be handled by documenting (in an IESG
    >> note?) as things that must be fixed before going to proposed.

    Julien> [...]
  
    >> HIP's handling of lost state seems insufficient to guarantee
    >> interoperability. Section 6.16 allows a HIP node to drop state
    >> at any time. However there is no mandatory to implement
    >> mechanism to recover other than waiting for a potentially very
    >> long timeout.  Implementations MAY send ICMP messages;
    >> implementations may respond to these messages. But there is not
    >> actually a mechanism that people have to make available to
    >> solve this.

    Julien> I believe Section 6.16. is a left-over from pre
    Julien> CLOSE/CLOSE_ACK handshake times (See version -00, Section
    Julien> 8.9) since the problem Sam is describing is IIRC what made
    Julien> Erik Nordmark comes with the CLOSE/CLOSE_ACK handshake,
    Julien> and led us to integrate it in the protocol.
    Julien> Section 6.16 should simply be deleted, IMHO.

I think this would be a significant improvement.  You still have
issues on reboot, but much less of a problem.

    Julien> [...]
 
    >> Section 6.2 of the base spec says that the IP address a packet
    >> arrives/is sent on should be ignored. The problem with this
    >> approach is that different interfaces have different security
    >> properties. I may well be willing to send data without
    >> confidentiality protection over a interface internal to a
    >> corporation but not over an external interface. This
    >> interaction would need to be carefully explored and reasonable
    >> standard. Thinking about HIP interacts with mandatory access
    >> control in the SPD is also going to be challenging. I discuss
    >> one case of this below.

    Julien> I understand Sam's point about willingness to *send*
    Julien> non-confidentiality protected over internal vs.  external
    Julien> interfaces.

    Julien> But I miss the link with Section 6.2. which describes
    Julien> "Processing *Incoming* Application Data"...

Ah, thanks for catching this.  I missed a point from my discuss
turning raw notes into text I hoped someone else could understand.  My
concern with section 6.2 is that there is no requirement that the HIT
on the inbound packet match the expected HIT for the SA.  I understand
that this needs to be said in a transport-neutral manner, but I think
it is critical.

    Julien> [...]

    >> In the ESP document , how does HIP interact with the SPD?
    >> Suppose I have an SPD entry saying that traffic to 18/8 needs
    >> to be protected. Suppose that I contact a machine via HIP whose
    >> HIT happens to resolve to something in 18/8. Do I expect double
    >> encapsulation?

    Julien> HITs are now ORCHIDs (see draft-laganier-ipv6-khi), i.e. a
    Julien> special type of IPv6 address which begin with prefix
    Julien> 2001:10::/28 (allocated in the IPv6 address space for
    Julien> ORCHIDs).

    Julien> Because of that, the HIT-is-an-IP-in-SPD situation
    Julien> described above cannot happen.

No.  That's not the situation I was describing.  In order to contact
node node identified by HIT X, I need to find a locator with a given
IP address.  Let's say I find that HIT X has IP address 18.18.0.2.
That IP address is covered by my SPD.  Depending on how HIP interacts
with my IPsec stack I may or may not get double encapsulation.

    Julien> I'm now thinking that since now HITs are IP addresses, we
    Julien> may just use the IPsec SPD to specify:

    Julien> from 2001:10::/28 to 2001:10::/28 -> protect from
    Julien> 2001:10::/28 to ^(2001:10::/28) -> block

    Julien> In addition, we might want a flag for corresponding PAD
    Julien> entries similar to what BTNS does (BTNS_OK), e.g.  HIP_OK.

I think in the case of HIP you get this by saying that HIP rather than
the IKE is the protocol to use for that PAD entry.
You already get that in 4301.

    >> Since HIP and IPsec share a common SPI space, and traffic on
    >> any HIP SPI completely bypasses IPsec policy. (Think about
    >> Steve Kent's usual rant about IPsec being more than just a
    >> means to apply cryptographic security mechanisms to traffic.)
    >> The assurances that IPsec provides are easily broken with HIP,
    >> since inbound HIP traffic bypasses the IPsec SPD and gets
    >> handed directly to HIP, which logically has its own SPD.

    Julien> See my comment above on introducing HIP SPD entries with
    Julien> ORCHIDs as selectors, and a HIP_OK PAD entry so that HIP
    Julien> traffic no longer bypasses IPsec, but is in fact IPsec,
    Julien> with a different key management protocol (HIP).

    >> It is not clear to me exactly how to avoid this situation, or
    >> what to add to the document to warn about this security
    >> consideration. A long discussion may be needed. Since the
    >> document is intended for Experimental RFC, this may be an
    >> acceptable situation, but this must be resolved for this

    Julien> Do you think specifying IPsec PAD and SPD entries for HIP
    Julien> would solve these issues?

As best I can tell, yes.
It's critical though that the SPD entry for a given SA be locked down to that /128 per my discussion about 6.2.