Stephen Kent | 2 Sep 18:08 2008
Picon

Re: Marking ESP-NULL packets

At 7:18 AM +0300 8/31/08, Yoav Nir wrote:
>...
>
>I agree, but in today's Internet, end-to-end paths will have some 
>middleboxes along the path that actually do examine the content to 
>some extent: firewalls, IPS devices, and NAT devices.

It depends on where you are :-), and the policy of the boxes in 
question. An IDS might LIKE to examine content, but if if does not 
have a tight link to a firewall, it may just be disappointed by an 
inability to examine content.

>
>...this,
>
>See discussion in the archives from 6-Aug and 7-Aug entitled 
>"Motivation for ESP-null marking", particularly two responses from Ken 
>Grewal.

I'll go back and check; thank's for the pointer.

>...
>
>As you've said, it's only the middlebox that inspects the packets, and 
>they already do it at the same data rate. It's not really necessary to 
>measure entropy. They only need to run their usual inspection, and get 
>random data instead of the protocol they were expecting.

maybe, maybe not. And

(Continue reading)

Grewal, Ken | 2 Sep 23:13 2008
Picon

Re: Marking ESP-NULL packets

I agree with Steve's comments from below that AH is probably not the way forward to resolve this.

The two reasons cited are...
- Inability to operate under NAT environments, which would require additional changes to the protocol, so
why not use ESP as a base for the changes instead of AH? NATs will be around for the foreseeable future; even
as we migrate to IPv6 where in addition to tunneling techniques, we will encounter translation
techniques (see renewed interest in specifying a standards-based replacement for NAT-PT).

- Performance costs (especially in HW) due to mutable fields in the headers that need to be removed from the
ICV calculation.

There have been extensive debates on deprecating AH based on these and other reasons and proposing to
extend AH now will require revisiting those topics again.

Separately, the policy applied by intermediate devices can be dependent on the functionality required
and the capabilities of that device and hence vary case by case. An IDS/IPS is one example of such a device. I
cited some simple examples of these policies and will let others provide more extensive use cases.

Currently, IT departments often choose to forego IPsec in favor of having network management tools
perform routine network functions. The ability to use IPsec AND preserve the existing (and future)
network monitoring/diagnostics tools using a simple ESP wrapper further enables the application of
IPsec beyond the VPN/remote access environments of today.

Thanks,
- Ken

>-----Original Message-----
>From: ipsec-bounces <at> ietf.org [mailto:ipsec-bounces <at> ietf.org] On Behalf Of
>Stephen Kent
>Sent: Tuesday, September 02, 2008 9:09 AM
(Continue reading)

Grewal, Ken | 2 Sep 23:19 2008
Picon

Re: Motivation for ESP-null marking

Hi Tero,
Apologies for the delayed response, but looks like this slipped under the Radar.

A large part of your message is promoting a heuristics based approach, which was also suggested in hallway
conversations in Dublin. In order to evaluate this further, including performance / cost /
extensibility, I would encourage someone to submit a specification on the heuristics algorithms to
employ and perhaps also the associated probability of false positives (where the same conclusion may be
reached by running these heuristics on encrypted data). This way it can be evaluated on merit against the
current proposal.

Other comments inline...

Thanks,
- Ken

>-----Original Message-----
>From: Tero Kivinen [mailto:kivinen <at> iki.fi]
>Sent: Tuesday, August 12, 2008 4:53 AM
>To: Grewal, Ken
>Cc: Yaron Sheffer; ipsec <at> ietf.org
>Subject: Re: [IPsec] Motivation for ESP-null marking
>
>Grewal, Ken writes:
>> >Let us ignore the details of the solution proposals for a while (1
>> >protocol number vs. 2, ESP wrapper vs. keeping the existing ESP
>> header),
>> >and consider whether there is a need to have any solution at all for
>> >this problem:
>> [Ken] I am surprised that there are questions being raised about this
>> goal, given that its presence in the charter indicates that it's a
(Continue reading)

Keith Welter | 2 Sep 23:34 2008
Picon

Question about deleting a half-open child SA


Suppose the initiator sends an SA payload that contains both an AH and ESP proposal.  Before receiving the response, the initiator decides to close the half-open child SA.  I assume that the informational request should include two delete payloads, one for AH and one for ESP.  Is that correct?

Related to that question, I don't see a requirement that all proposals in an SA payload have the same SPI.  So, in this example, it would be permissible for the AH and ESP proposals to have different SPIs.  Is that correct?

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Pasi.Eronen | 3 Sep 08:01 2008
Picon

My notes about IKEv2bis

A while ago, I promised to send my list of "things that need to be 
looked at" about IKEv2bis to the mailing list.

These are a mix of things that IMHO might be wrong, might benefit from
some editorial changes/clarifications, things that just need some
thinking to check if they're actually correct, and other random notes.

--------

Abstract: needs rephrasing, include at least "IKE is a component of
IPsec used for performing mutual authentication and establishing and
maintaining security associations (SAs)" from RFC 4306 abstract.

1.5: Needs rephrasing, maybe merge with 2.21.

2.4: "receiving parties need to deal with it in other requests" Is
this right, and how it's dealt with? And only requests, not responses?

2.5: Needs to clarify what exactly the message containing the
INVALID_MAJOR_VERSION notification looks like (Fukumoto Atsushi's
email 2007-06-12)

2.6 (near Clarif-2.1) and 2.6.1: needs rephrasing/more explanation
(especially "MUST NOT fail" is unclear).

2.7 and 3.3.6, possible contradiction about INVALID_KE_PAYLOAD ("MUST
again propose its full set of." vs. "SHOULD, however, continue
to propose its full supported set")

2.7 and 3.3.6: text about INVALID_KE_PAYLOAD might need clarification:
if none of the proposed groups is acceptable, NO_PROPOSA_CHOSEN is the
correct notification (thread "Is this a good use of the
INVALID_KE_PAYLOAD notification", May 2007)

2.8: might be wrong place for Clarif-5.9.

2.8: maybe clarify that when rekeying, the new SA might have
different traffic selectors and algorithms than the old one?

2.8: probably should clarify what you do when you receive
NO_PROPOSAL_CHOSEN during IKE_SA rekeying

2.9.1: might not fully consistent with RFC 4301 regarding decorrelated
policy etc. (emails 2008-11-28 and 2008-11-30).

2.19: text about FAILED_CP_REQUIRED needs editing, and it's in wrong
place (breaks flow of other text)

2.19 and 2.19.1: needs editing/rephrasing, perhaps merging these
two sections to improve flow.

2.19 and 3.15: text about configuration payloads is still in
two places; either merge or more clearly separate what goes where.

2.23: lots of bullets here, could be formatted in more readable way?

5: "implementation using EAP MUST also use strong authentication",
change from RFC 4306, and "strong" is ambiguous (e.g. is "group secret"
strong?)

8.2: RFCs 2251, 2486, and 3513, and FIPS 180-1, have been obsoleted by
newer documents.

Text doesn't cover all the exchange collisions from RFC 4718 Section
5.11 yet (but I doubt implementors will get many of those right anyway...).

The document probably should talk about PAD in the context of 
IKE_SA authentication, and traffic selector authorization.

INVALID_IKE_SPI needs some clarification (emails from 2007-10-17 to
2007-10-19)

There should be text about how a protected INVALID_SPI notification
is processed.

Mapping of incoming IKE packets to IKE_SA needs clarification
(maybe in 2.1, 2.6 or 3.1): it's done using the recipient SPI only,
not e.g. using the source IP address.

The text about transport mode NAT-T isn't right: it really needs to
discuss how the SPD and TS payloads work, and it seems incremental
checksum fixup can't work as described (I have longer notes about this
topic based on discussions with Tero in December 2007).

ADDITIONAL_TS_POSSIBLE probably needs clarification: it seems the
recipient can't really use this for anything else than
logging/debugging, if even that (thread August 2008)

Do traffic selectors containing port numbers make sense if the 
protocol is 0? (thread August 2008)

Would it be useful to have a separate section describing "CHILD_SA
attributes" like ESN, ESP_TFC_PADDING_NOT_SUPPORTED, IPCOMP_SUPPORTED,
NON_FIRST_FRAGMENTS_ALSO, etc.?

Do we need text about simultaneous reauthentication and/or
simultaneous initiation of IKE_SAs? (email 2007-08-21, thread June
2008)

Should we support OPAQUE protocol selectors for IPv6 (thread May/June
2007)

Should we move features with no known implementations from the main
text to an appendix?

The document will eventually need a "changes to RFC 4306" (or at 
least "changes that implementors of RFC 4306 should look at") 
section.

Tero's email on 2008-07-29 had bunch of things.

Best regards,
Pasi
Yoav Nir | 3 Sep 08:52 2008
Picon

Re: Question about deleting a half-open child SA

Hi Keith

On Sep 3, 2008, at 12:34 AM, Keith Welter wrote:

Suppose the initiator sends an SA payload that contains both an AH and ESP proposal.  Before receiving the response, the initiator decides to close the half-open child SA.  I assume that the informational request should include two delete payloads, one for AH and one for ESP.  Is that correct?

There's no such thing as a half-open Child SA. What you describe is a proposal that the initiator still hasn't received a reply for. There is no SA yet, at least on the initiator side. In fact the initiator cannot know at this point whether or not an SA is even going to be established, because the peer may reject the proposal, or else may have rebooted.

For this reason, it is not appropriate at this point to begin constructing the Informational message with the DELETE payloads, as this message will be nonsensical if the CCSA request is rejected. Instead, the initiator must wait until a response is received. Then it can either (1) do nothing, if the request was rejected or (2) delete the one SA that actually got created.

Doing it as you propose, would definitely result in a DELETE message for a non-existing SA, which is bad, although I don't see any text in RFC 4306 or 4306bis about what action the responder should take when it receives such a request. It's probably not delete-the-ike-sa bad, but still something you shouldn't do.

Related to that question, I don't see a requirement that all proposals in an SA payload have the same SPI.  So, in this example, it would be permissible for the AH and ESP proposals to have different SPIs.  Is that correct?

Yes, that's correct. The SA payload is ready to offer protocols of variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe someday we'll have superESP with an 8-byte SPI. In that case, an SA payload with two proposals, one for AH and the other for superESP would have to have different SPIs. As it is, it's still possible to use different values, but it's not a requirement.


_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Tero Kivinen | 3 Sep 13:14 2008
Picon
Picon

Question about deleting a half-open child SA

Keith Welter writes:
> Suppose the initiator sends an SA payload that contains both an AH and ESP 
> proposal.  Before receiving the response, the initiator decides to close 
> the half-open child SA.  I assume that the informational request should 
> include two delete payloads, one for AH and one for ESP.  Is that correct?

There is no really working method to delete the SA until it is
created, i.e. you cannot delete half open SAs. Even if you send delete
notifications, it might be possible that the responder has not yet
seen the SA creation packet, thus delete SA would refer to unknown
SPIs, and responder would reply with error to both of them.

The best is simply wait for the SA negotiation to finish and delete it
after that. This is anyways required if the other end only supports
window size of 1, as you cannot send delete notifacation before you
get reply back to your create child SA exchange.

> Related to that question, I don't see a requirement that all proposals in 
> an SA payload have the same SPI.  So, in this example, it would be 
> permissible for the AH and ESP proposals to have different SPIs.  Is that 
> correct?

Yes. The SPIs does not need to be same. There might be for example
some implementation which could even allocate the SPIs for different
protocols on different ranges. 
--

-- 
kivinen <at> safenet-inc.com
Keith Welter | 4 Sep 19:23 2008
Picon

Re: IPsec Digest, Vol 53, Issue 3


Thanks Yoav.  I have a couple more questions inline below.

> Hi Keith
>
> On Sep 3, 2008, at 12:34 AM, Keith Welter wrote:
>
> > Suppose the initiator sends an SA payload that contains both an AH  
> > and ESP proposal.  Before receiving the response, the initiator  
> > decides to close the half-open child SA.  I assume that the  
> > informational request should include two delete payloads, one for AH  
> > and one for ESP.  Is that correct?
>
> There's no such thing as a half-open Child SA. What you describe is a  
> proposal that the initiator still hasn't received a reply for. There  
> is no SA yet, at least on the initiator side. In fact the initiator  
> cannot know at this point whether or not an SA is even going to be  
> established, because the peer may reject the proposal, or else may  
> have rebooted.
I'm curious why you say there's no such thing as a half-open child SA.
If an implementation creates the child SA state in the process of
sending the CCSA request then it seems like that it would be reasonable
to call this child SA half-open until the CCSA response is received.
RFC 4306 section 2.6 uses the term "half-open" to describe IKE SAs so
I'm confused why the same term couldn't be applied to a child SA.
Are you implying that an implementation should not create any child SA
state until the CCSA response is received?

>
> For this reason, it is not appropriate at this point to begin  
> constructing the Informational message with the DELETE payloads, as  
> this message will be nonsensical if the CCSA request is rejected.  
> Instead, the initiator must wait until a response is received. Then it  
> can either (1) do nothing, if the request was rejected or (2) delete  
> the one SA that actually got created.
>
> Doing it as you propose, would definitely result in a DELETE message  
> for a non-existing SA, which is bad, although I don't see any text in  
> RFC 4306 or 4306bis about what action the responder should take when  
> it receives such a request. It's probably not delete-the-ike-sa bad,  
> but still something you shouldn't do.
Ok, thanks for the clafication.

>
> > Related to that question, I don't see a requirement that all  
> > proposals in an SA payload have the same SPI.  So, in this example,  
> > it would be permissible for the AH and ESP proposals to have  
> > different SPIs.  Is that correct?
>
> Yes, that's correct. The SA payload is ready to offer protocols of  
> variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe  
> someday we'll have superESP with an 8-byte SPI. In that case, an SA  
> payload with two proposals, one for AH and the other for superESP  
> would have to have different SPIs. As it is, it's still possible to  
> use different values, but it's not a requirement.
Ok, I want to probe a little deeper here.  RFC 4301 section 4.1 says:
   "For an SA used to carry unicast traffic, the Security Parameters
  Index (SPI) by itself suffices to specify an SA.  (For information on
  the SPI, see Appendix A and the AH and ESP specifications [Ken05b,
  Ken05a].)  However, as a local matter, an implementation may choose
  to use the SPI in conjunction with the IPsec protocol type (AH or
  ESP) for SA identification."
Suppose an implementation choses to use the SPI in conjunction with
the IPsec protocol for IPsec SA identification.  Such an implementation
could have multiple IPsec SAs with the same SPI but different protocols.
It seems like this could cause interoperability problems if these SAs
are negotiated with a peer that uses only the SPI for SA
identification.  If that assumption is correct, it seems like an
implementation should avoid using the same SPI, differentiated only by
protocol, with a given peer.  In other words, if an implementation
uses SPI x for an ESP SA it should not attempt to use SPI x for an AH
SA with the same peer simultaneously.  Would you agree?
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Yoav Nir | 8 Sep 11:18 2008
Picon

Re: IPsec Digest, Vol 53, Issue 3


On Sep 4, 2008, at 8:23 PM, Keith Welter wrote:


Thanks Yoav.  I have a couple more questions inline below.

> Hi Keith
>
> On Sep 3, 2008, at 12:34 AM, Keith Welter wrote:
>
> > Suppose the initiator sends an SA payload that contains both an AH  
> > and ESP proposal.  Before receiving the response, the initiator  
> > decides to close the half-open child SA.  I assume that the  
> > informational request should include two delete payloads, one for AH  
> > and one for ESP.  Is that correct?
>
> There's no such thing as a half-open Child SA. What you describe is a  
> proposal that the initiator still hasn't received a reply for. There  
> is no SA yet, at least on the initiator side. In fact the initiator  
> cannot know at this point whether or not an SA is even going to be  
> established, because the peer may reject the proposal, or else may  
> have rebooted.
I'm curious why you say there's no such thing as a half-open child SA.
If an implementation creates the child SA state in the process of
sending the CCSA request then it seems like that it would be reasonable
to call this child SA half-open until the CCSA response is received.
RFC 4306 section 2.6 uses the term "half-open" to describe IKE SAs so
I'm confused why the same term couldn't be applied to a child SA.
Are you implying that an implementation should not create any child SA
state until the CCSA response is received?

The half-open SA in RFC 4306 is an IKE SA, and it is on the responder, not the initiator. The meaning of the term is that the IKE SA already has keys, but is not yet authenticated. A child SA is just about exchanging keys, so there's no middle state. But this is just terminology.
 
> For this reason, it is not appropriate at this point to begin  
> constructing the Informational message with the DELETE payloads, as  
> this message will be nonsensical if the CCSA request is rejected.  
> Instead, the initiator must wait until a response is received. Then it  
> can either (1) do nothing, if the request was rejected or (2) delete  
> the one SA that actually got created.
>
> Doing it as you propose, would definitely result in a DELETE message  
> for a non-existing SA, which is bad, although I don't see any text in  
> RFC 4306 or 4306bis about what action the responder should take when  
> it receives such a request. It's probably not delete-the-ike-sa bad,  
> but still something you shouldn't do.
Ok, thanks for the clafication.

>
> > Related to that question, I don't see a requirement that all  
> > proposals in an SA payload have the same SPI.  So, in this example,  
> > it would be permissible for the AH and ESP proposals to have  
> > different SPIs.  Is that correct?
>
> Yes, that's correct. The SA payload is ready to offer protocols of  
> variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe  
> someday we'll have superESP with an 8-byte SPI. In that case, an SA  
> payload with two proposals, one for AH and the other for superESP  
> would have to have different SPIs. As it is, it's still possible to  
> use different values, but it's not a requirement.
Ok, I want to probe a little deeper here.  RFC 4301 section 4.1 says:
   "For an SA used to carry unicast traffic, the Security Parameters
  Index (SPI) by itself suffices to specify an SA.  (For information on
  the SPI, see Appendix A and the AH and ESP specifications [Ken05b,
  Ken05a].)  However, as a local matter, an implementation may choose
  to use the SPI in conjunction with the IPsec protocol type (AH or
  ESP) for SA identification."
Suppose an implementation choses to use the SPI in conjunction with
the IPsec protocol for IPsec SA identification.  Such an implementation
could have multiple IPsec SAs with the same SPI but different protocols.
It seems like this could cause interoperability problems if these SAs
are negotiated with a peer that uses only the SPI for SA
identification.  If that assumption is correct, it seems like an
implementation should avoid using the same SPI, differentiated only by
protocol, with a given peer.  In other words, if an implementation
uses SPI x for an ESP SA it should not attempt to use SPI x for an AH
SA with the same peer simultaneously.  Would you agree?

That is not necessary, as each IKE peer chooses the SPI for the INBOUND SA. It does not choose the SPI for the outbound SA, so it can't make any assumptions about the outbound SPI being unique per-host, unique per-protocol, or unique in any sense of the word. The policy leads to the selection of the outbound SA, and the SPI is just a property of that SA.  For inbound SAs, an implementation should choose a unique SPI (at least per protocol) so that it can distinguish which SA is associated with that SPI. It should be globally unique rather than per-peer, so that we can allow mobility.
In other words, in inbound processing, the SPI (or SPI + protocol) is the key to the table. In outbound processing, it's just a value.

_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Yoav Nir | 8 Sep 15:35 2008
Picon

Review of the RoHC over IPsec drafts

Hi all

At Yaron's request I've gone over the three drafts related to RoHC over IPsec tunnels.

The three drafts are:
  • draft-ietf-rohc-hcoipsec - integration of RoHC over IPsec SAs
  • draft-ietf-rohc-ikev2-extensions-hcoipsec - IKEv2 extensions to negotiate RoHC over IPsec
  • draft-ietf-rohc-ipsec-extensions-hcoipsec - IPsec extenstions

Overall the drafts drafts seem good, and in my opinion could offer a substantial benefit for IPsec tunnels, especially where the bandwidth to one or both endpoints is constrained. Here's my comments.

  • The IKE & IPsec drafts talk about the use of integrity algorithms to verify that decompression was successful. According to section 2.1 of the IKEv2 draft, these algorithms are the same algorithms (with associated keys) as those used in IPsec. I can't figure out why you would want this. The entire packet, compressed header and data included, is already integrity protected by IPsec. An attacker can't flip any bits because of the ESP ICV, so the RoHC ICV is simply there to detect decompression errors. I don't see why we need to exceed the recommendation in RFC 4995 to use CRC. Even if you have decided that you want to upgrade error-detection ICV to a cryptographically strong one, HMAC doesn't offer any benefit that I can see - you could use straight MD5 or SHA-1 without any key, but I still don't see why CRC is not good enough.
  • The introduction to draft-ietf-rohc-hcoipsec-08 says that "However, since current specifications for RoHC detail its operation on a hop-by-hop basis, it may require extensions to enable its operation over IPsec SAs.". This is not explained later. An IPsec tunnel is very much like a single hop (for the tunneled traffic), so I don't see why special extensions would be needed.
  • Section 4 of draft-ietf-rohc-hcoipsec-08 needs some rewording. Is the second sentence about the TFC feature of IPsec? About the padding feature of RoHC? About the problem in general? You might want to add discussion about whether it is recommended to use RoHC padding or IPsec TFC to avoid the problem.
  • Section 5.2 of draft-ietf-rohc-hcoipsec (last paragraph) has some strange text about ESP-NULL, which I don't understand. Why should ESP-NULL be any different than any other ESP method?
  • There is, however, something to consider about ESP-NULL. Some middleboxes may want to inspect traffic that is encrypted with ESP-NULL (see draft-grewal-ipsec-traffic-visibility-00). It's possible that RoHC will cause those middleboxes to drop all traffic that is compressed, because they won't be able to parse the compressed headers.
  • Section 6.1.2 says "f the RoHC protocol requires bi-directional communications, two SAs must be instantiated between the IPsec implementations." This is a non-issue, since IKE creates SAs in pairs anyways. So I don't see the point in the recommendation to use only non-feedback profiles. You may want to mention that the decompressor needs to relay feedback to the appropriate compressor

Regarding the IKEv2 draft, I only have several comments about section 2.1:
  • It's common for IKEv2 drafts to have at the beginning a figure of the entire payload and then explain the various fields.
  • The explanation of the "Critical" bit is incorrect. It does not refer to the content of the payload, only to the type of the payload, in this case "Notify". The bit MUST be off for Notify payloads, because all IKEv2 implementations must support it. Similarly, there's not reason to define the content of the reserved bits, because they're the same as for any payload.
  • Protocol ID field: According to the first paragraph of 2.1, the notification is only in CCSA and IKE_AUTH. So there's no case where this notification is used outside of the creation of the child SA, and there's no need to ever set the protocol ID.

 
_______________________________________________
IPsec mailing list
IPsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Gmane