Re: [IPsec] Proposed work item: WESP extensibility
I am opposed to pursing this work at this time. The ongoing discussion on the list suggests that the arguments put forth for WESP use in the OSPFv3 context, the first concrete proposal outside of the middlebox inspection context that motivated WESP, have not been validated. The presentation in Hiroshima listed a variety of possible use cases, without providing any detailed analysis, and at least one such case was considered and rejected by the IPSEC WG on at least two occasions. My recollection is that Pasi agreed with my suggestion that at least 2 or 3 valid use cases need to be thoroughly vetted before the WG pursue this as a new work item. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: Labelled IPsec
I think that there has been insufficient discussion of whether those who wish to make use of IPsec to enforce mandatory access controls require the facilities described by the folks who have proposed this. At the WG meeting 2 weeks ago I made two observations: - possible use of CIPSO for carrying labels had not been fully discussed - use of tunnel mode to protect such labels in the inner header did not appear to have been considered I think it is incumbent on those who wish to pursue this work to provide more persuasive arguments. It also seems appropriate to have a discussion of whether mandatory, label-based controls are sufficiently mainstream to warrant bringing them back into IPsec at this time, or whether this is more of a research topic. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
Jack, Thanks for describing the additional selection criteria that must be employed to avoid the problem I cited. Given this more complete description of the selection criteria, I am not convinced that that is a significant benefit for using WESP in this context. - Whether using WESP or just ESP-NULL, the router needs to determine that the packet is addressed to it. This means looking for either a unicast address (per interface?) or a multicast address. I thought that the traffic of interest would arrive on a multicast address. If so, then this is a very easy check. - Traffic other than OSPF can be addressed to the router, but I'm not sure what other traffic would be multicast. For unicast traffic addressed to the router, if some of that is protected using ESP with confidentiality, then the address check might have to be extended to include a source address as well. - There is an assumption that the OPSFv3 traffic is (ultimately) protected using ESP-NULL. The next check that you described, i.e., looking for a few bits that indicate whether the payload is OSPF and appears to be a HELLO or ACK, is the real focus of this thread. There appears to be a couple of cases: - If all multicast traffic directed to the router and protected using ESP is ESP-NULL, then WESP seems to help ONLY if there are algorithms being used for different SAs, AND if those algorithms result in different offsets for the start of the ESP-NULL payload. It's not clear that this is a realistic case. But, in this case, using WESP could avoid the need to check the SPI in the packet. What's not clear is whether checking for WESP and extracting the offset info is faster than matching against a set of SPIs. - if some multicast traffic directed to the router is protected with ESP with confidentiality, in addition to the ESP-NULL OSPF traffic, then one would need to check SPI values to differentiate between these two classes of traffic. So, the question of whether we have one multicast SA for this traffic, or potentially a lot of these SAs is potentially relevant. As I mentioned in my previous message, this is not completely clear to me from 4552. You didn't respond to that part of my message, so I don't know if that means you find the RFC unclear on this point as well, or if you didn't think it mattered to this discussion. Well, if appears to matter, if one believes that the number is substantial. So, the bottom line appears to be that WESP might be better than just using ESP-NULL, depending on the number of multicast SAs that terminate at the router, that make use of ESP, and maybe whether the ones that use ESP make use of different integrity algorithms that result in different offsets. That is a lot of IFs for which we have yet to get an answer. In any case, as I noted earlier, because of the use of manual keying in this context, selecting a subset of packets for out-of-order processing does not impose any burden on the IPsec for the remaining packets, so all of the comments about that issue were red herrings. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
At 12:19 AM +0300 11/30/09, Valery Smyslov wrote:
>>>For someone, who spent quite a lot of time working in this area, it is not
>>>difficult fo figure out what is really important and what is not. But, I
>>>think,
>>>a newcomer could be confused by a long list of all possible numbers.
>>
>>This answer is inconsistent, and that's the crux of the issue I have with your
>>concern. We very much want developers to look at the IANA registry;
>>it's the only way for them to know definitively what values will cause
>>interoperability. Yet you say things like "a newcomer could be confused
>>by a long list of all possible numbers". You can't have it both ways.
>
>You probably speaks about "ideal" developers. I speak about real people.
>I've seen a few cases when people implemented a bunch of really
>unnecessary things just because "it was in standard".
We still agree, and your answer is still inconsistent. If you worry about those
type of developers, then you must want to get rid of the IANA registry, because
that is what is giving them the silly ideas.
>Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not defined
>in IANA.
>For me this is inconsistent. Either change two abovementioned lines to:
>
>1 768-Bit MODP Group[RFC4306]
>2 1024-Bit MODP Group [RFC4306]
>
>14 2048-Bit MODP Group [RFC3526]
>15 3072-Bit MODP Group [RFC3526]
>16 4096-Bit MODP Group [RFC3526]
>17 6144-Bit MODP Group [RFC3526]
>18 8192-Bit MODP Group [RFC3526]
Sorry, I misunderstood what you were saying. Yes, that is a good suggestion;
I'll make it happen.
>>>EAP numbers listed in RFC4306 might also be changed in future,
>>>so from your logic it's better just to point to
>>>http://www.iana.org/assignments/eap-numbers, right?
>>
>>Yes, but *only* if the names and numbers we use in this document match those
>>exactly
>>*and* the WG is willing to cede change control to the EAP methods we use to
>>the IANA
>>registry that we do not have input to. So far, the WG hasn't said they want
>>to do that,
>>so I don't presume to make that change.
>
>I fail to understand your logic here. You seem to want to have ability to
>change
>already assigned numbers in IKEv2 in the future (and for this purpose remove
>them from RFC), but at the same time you seem to presume that other
>groups will not ever change their numbers.
I do not presume that. I presume that this WG is not concerned about it;
otherwise, we would have created our own IANA registry for the EAP values we
use. We didn't.
>I fail to understand how removing values from the RFC will help
>understanding the context for them.
The context for the values is "they are assigned and maintained by IANA". It is
not "they came from this RFC". You may not like that, but that's how the IETF
works.
>>>If you need extensions - go to IANA and look for added numbers,
>>>but core protocol must be implementable reading as few sources,
>>>as possible, preferrably one.
>>
>>Seriously: how hard is "two"? Any serious developer can go look at
>>a second URL to get the values.
>
>It's not hard, but what for? I see some drawbacks and I don't see
>how it will help interoperability.
Again: it helps interoperability if developers look in the IANA registry at the
time of coding and see changes have been made to what they thought was true
based only on reading an RFC.
>>>Tero's approach is a compromise. You will need the IANA only for
>>>few types of magic numbers, most of which don't affect protocol
>>>logic. I can leave with it.
>>
>>This seems inconsistent to me ("it's OK to need a second file for some things
>>but not others").
>
>I didn't say I like it. I said I can bear it. Tero has suggested removing
>values for Transform IDs only. Those values mostly are "external" to
>IKEv2 logic, it just "transfers" them between network, policy module,
>ipsec module and crypto module. Theoretically they should not affect
>IKEv2 itself (*). That's why I can bear removing them.
>
>(*) Unfortunately, they do affect: AEAD algorithms require special
>handling in construction proposals. But this is another story.
>I've been thinking that introducing a new Transform type for
>AEAD algorithms instead of reusing Encryption Algorithm Transform
>would probably have made protocol simpler and cleaner, but that was that.
Your second paragraph is a shining example of why this should have been done in
RFC 4306, and why we should not presume that what we do in IKEv2bis will be
held constant.
>>>As far as I understand, in this case new RFC must be issued,
>>>which will obsolete current one, won't it? If so, no contradiction.
>>
>>That is not true. The new RFC can update just a portion of the old one.
>>That is how this is normally handled in the IETF.
>
>In any case base RFC will be updated. And the first thing one mu
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
For someone, who spent quite a lot of time working in this area, it is not
difficult fo figure out what is really important and what is not. But, I
think,
a newcomer could be confused by a long list of all possible numbers.
This answer is inconsistent, and that's the crux of the issue I have with
your
concern. We very much want developers to look at the IANA registry;
it's the only way for them to know definitively what values will cause
interoperability. Yet you say things like "a newcomer could be confused
by a long list of all possible numbers". You can't have it both ways.
You probably speaks about "ideal" developers. I speak about real people.
I've seen a few cases when people implemented a bunch of really
unnecessary things just because "it was in standard".
No, you didn't get the point. I meant that Diffie-Hellman Group Transform
IDs table
in two cases doesn't assign individual numbers, just ranges. For example:
1-2 Defined in Appendix B [RFC4306]
14-18Defined in [RFC3526] [RFC3526]
So, in first case it just points back to RFC4306 Appendix B, where the
actual
numbers (what is 1 and what is 2) are assigned. Probably it may (and must)
be changed, but in its current form it's ridiculos - you went to IANA for
real numbers and have found only pointer back to RFC4306 where you
just have come from...
These are the full definition of the semantics of the groups. How would
you change this?
Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not
defined in IANA.
For me this is inconsistent. Either change two abovementioned lines to:
1 768-Bit MODP Group[RFC4306]
2 1024-Bit MODP Group [RFC4306]
14 2048-Bit MODP Group [RFC3526]
15 3072-Bit MODP Group [RFC3526]
16 4096-Bit MODP Group [RFC3526]
17 6144-Bit MODP Group [RFC3526]
18 8192-Bit MODP Group [RFC3526]
or, if you think that current situation is OK, then why no to change other
tables
in the same fashion and leave all numbers in the RFC. Just for example:
Value Next Payload TypeNotation Reference
--- - -
0 No Next Payload [RFC4306]
1-32 Reserved [RFC4306]
33-48 Defined in [RFC4306][RFC4306]
49-127Unassigned [RFC4306]
128-255 Private use [RFC4306]
At least this will made things consistent.
EAP numbers listed in RFC4306 might also be changed in future,
so from your logic it's better just to point to
http://www.iana.org/assignments/eap-numbers, right?
Yes, but *only* if the names and numbers we use in this document match
those exactly
*and* the WG is willing to cede change control to the EAP methods we use
to the IANA
registry that we do not have input to. So far, the WG hasn't said they
want to do that,
so I don't presume to make that change.
I fail to understand your logic here. You seem to want to have ability to
change
already assigned numbers in IKEv2 in the future (and for this purpose remove
them from RFC), but at the same time you seem to presume that other
groups will not ever change their numbers. By the way, at least one RFC
outside
ipsecme WG (I mean RFC5106, EAP-IKEv2) has already listed some of IKEv2
magic numbers (payload types) and has already presumed that they won't
change.
Now you suggest to make IKEv2 not self-contained again.
Correct, because we have already made many changes to the values that
developers need to know.
Those new values could be listed in IKEv2bis RFC, which will update RFC4306.
Of course, I understand that IANA registry is not another RFC, but
I still prefer single self-contained document for core protocol.
Of course, but your preference is at odds with the preference of someone
reading the document needing to understand the context for the values.
I fail to understand how removing values from the RFC will help
understanding the context for them.
If you need extensions - go to IANA and look for added numbers,
but core protocol must be implementable reading as few sources,
as possible, preferrably one.
Seriously: how hard is "two"? Any serious developer can go look at
a second URL to get the values.
It's not hard, but what for? I see some drawbacks and I don't see
how it will help interoperability.
Tero's approach is a compromise. You will need the IANA only for
few types of magic numbers, most of which don't affect protocol
logic. I can leave with it.
This seems inconsistent to me ("it's OK to need a second file for some
things but not others").
I didn't say I like it. I said I can bear it. Tero has suggested removing
values for Transform IDs only. Thos
[IPsec] Proposed work item: IKE/IPsec high availability and load sharing
This work item will define the problem statement and requirements for a solution that allows interoperable HA/LS device groups. Mixed-vendor clusters are specifically out of scope; but single-vendor clusters should be fully interoperable with other vendors' devices or clusters. The main challenge is to overcome the strict use of sequence numbers in both IPsec and IKE, in HA and LS scenarios. Following the Hiroshima discussion, the WI is initially focused on defining the problem, rather than a particular solution. Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-ipsecha-00.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on. If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!"). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Proposed work item: WESP extensibility
This draft proposes an extensibility framework for WESP, as well as several specific extensions. Proposed starting point: http://tools.ietf.org/id/draft-montenegro-ipsecme-wesp-extensions-00.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on. If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!"). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Proposed work item: Labelled IPsec
This work item proposes to extend IKEv2 (and IKEv1) so as to allow IPsec to be used in environments that require Mandatory Access Control. It is envisioned that this will be used by modern high-security operating systems, that go beyond the currently supported Multilevel Security (MLS). Proposed starting point: http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-context-01 and http://tools.ietf.org/html/draft-jml-ipsec-ikev1-security-context-01. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on. If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!"). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Proposed work item: Failure detection in IKEv2
This work item proposes an IKEv2 extension to allow an IKE peer to quickly and securely detect that its opposite peer has lost state. This is claimed to be quicker than the current method, which is based on time outs. Proposed starting point: http://tools.ietf.org/id/draft-nir-ike-qcd-05.txt or http://tools.ietf.org/html/draft-detienne-ikev2-recovery-03. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on. If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!"). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Proposed work item: IKEv2 password authentication (SPSK)
This draft proposes a particular method for mutual authentication of IKEv2 peers using a short, low quality shared secret (a.k.a. "password"). The proposal is to embed this method in the IKE exchange, rather than use EAP. Proposed starting point: http://tools.ietf.org/id/draft-harkins-ipsecme-spsk-auth-00.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on. If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!"). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Proposed work item: Childless IKE SA
This draft proposes an IKEv2 extension to allow the setup of an IKE SA with no Child SA, a situation which is currently disallowed by the protocol. Proposed starting point: http://tools.ietf.org/id/draft-nir-ipsecme-childless-01.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on. If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!"). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Proposed work item: EAP-only authentication in IKEv2
This draft proposes an IKEv2 extension to allow mutual EAP-based authentication in IKEv2, eliminating the need for one of the peers to present a certificate. This applies to a small number of key-generating EAP methods that allow mutual authentication. Proposed starting point: http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-eap-auth-07.txt. Please reply to the list: - If this proposal is accepted as a WG work item, are you committing to review multiple versions of the draft? - Are you willing to contribute text to the draft? - Would you like to co-author it? Please also reply to the list if: - You believe this is NOT a reasonable activity for the WG to spend time on. If this is the case, please explain your position. Do not explore the fine technical details (which will change anyway, once the WG gets hold of the draft); instead explain why this is uninteresting for the WG or for the industry at large. Also, please mark the title clearly (e.g. "DES40-export in IPsec - NO!"). ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME rechartering
Hi everyone, The following 7 messages request your input regarding the activities that were proposed for the next phase of the IPsecME WG. This is an open process, and we specifically request that you reply to the mailing list, rather than privately, whether you are committing to review/author a draft or on the contrary, arguing why the working group should not work on it. Also, please limit your commitment to what's reasonable - we will be chasing you to review those drafts! Please reply separately for each proposal, keeping its name in the title. We are asking for your replies by Monday, Dec. 7. If you already committed to review/participate in any proposals during the Hiroshima meeting, or if you're a current author, you don't have to resend (you may want to check the meeting minutes for correctness, http://tools.ietf.org/wg/ipsecme/minutes). Based on these inputs, Paul, Pasi and I will evaluate which of the proposals has enough interest to work on. Thanks, Yaron ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
