Re: [IPsec] EAP Identity request in IKEv2
Resending the query again, as I did not see any response to this query.
It looks like additional EAP ID request to the client is not needed, so
I think we should move
the should to SHOULD again. Any thoughts?
Thanks,
Srinivas
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Srinivasu S R S Dhulipala (srinid)
Sent: Monday, November 09, 2009 3:12 PM
To: ipsec@ietf.org
Subject: [IPsec] EAP Identity request in IKEv2
Hi,
I see that RFC4306 has the following lines at the end of Sec3.16:
Note that since IKE passes an indication of initiator identity in
message 3 of the protocol, the responder SHOULD NOT send EAP Identity
requests. The initiator SHOULD, however, respond to such requests if
it receives them.
I see that from draft-ietf-ipsecme-ikev2bis-01, SHOUD and SHOULD NOT
were demoted to
should and should not, the text now looks as below:
{{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an
indication of initiator identity in message 3 of the protocol, the
responder should not send EAP Identity requests. The initiator may,
however, respond to such requests if it receives them.
Also, The initiator SHOULD is now The initiator may.
I would like to understand why these changes were done. Why do we need
to do an EAP-ID
request as IDi should carry an indication of the client's identity?
Thanks,
Srinivas
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication
The text is a little vague here, because the draft only describes the use of
EAP, and does not mandate anything for an AAA server.
If the gateway is also the EAP authenticator, then it makes no sense to send
the identity request, because the reply has already been received in packet #3.
If the EAP authenticator is separate, it still does not make sense, as the
gateway could have passed the identity hint to the authenticator. But some AAA
servers always begin a session by requesting an identity. We don't want to make
their use a SHOULD NOT. We don't want to mandate anything for them. So we
accept that some servers may send an identity request even though the hint is
already given.
Since the gateway acts as a pass-through, the requirement here is more for the
client, which is typically more integrated. The client should be prepared to
give an identity hint both in IKE and later in the EAP session.
On Nov 11, 2009, at 4:05 PM, Srinivasu S R S Dhulipala (srinid) wrote:
Hi Yoav,
Thanks for the quick response. Please see inline.
-Original Message-
From: Yoav Nir [mailto:y...@checkpoint.com]
Sent: Wednesday, November 11, 2009 7:23 PM
To: Srinivasu S R S Dhulipala (srinid)
Cc: Amjad Inamdar (amjads); ipsec@ietf.org
Subject: Re: [IPsec] Clarification on identities involved in
IKEv2EAPauthentication
On Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) wrote:
2) If not same, what purpose should each of the above identities
serve
1) mainly used as a hint for the gateway as to which AAA server to
choose
2) It's the AAA server that may request the identity, and it's
internal to AAA. It doesn't play in IKE
[SRINI] Does this imply that gateway SHOULD not send EAP identity
request to the client,
we see that one 3rd party IKEv2 client is sending IP
address
as IDi, from which we can't
take any hints. Moreover, the same client is expecting an
EAP-ID request to be sent,
else EAP is failing.
I've started another thread about why did we demote
SHOULD
to should if the gateway is
Not supposed to send EAP-identity request to the client. I
think we should promote it back.
The gateway never sends any EAP identity requests at all. If such a
request exists, it is sent by the AAA server. The gateway serves only as
a pass-through.
[SRINI] Text below from sec 3.16 of the bis hints that responder may
send, but it says
It should not. In RFC 4306, it was SHOULD NOT, in the bis
it is should not.
{{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an
indication of initiator identity in message 3 of the protocol, the
responder should not send EAP Identity requests. The initiator may,
however, respond to such requests if it receives them.
Thanks,
Srinivas
For that reason, there is typically no reason for the gateway to inspect
the contents of the EAP payload.
Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] RFC4869 bis submitted
A bis has been submitted for RFC 4869, Suite B Cryptographic Suites for IPsec. It is available at http://tools.ietf.org/html/draft-law-rfc4869bis-00 This Internet-Draft makes several minor changes to the suites in RFC 4869 and incorporates comments that have been posted to the ipsec mailing list. Laurie Law National Information Assurance Research Laboratory National Security Agency ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Clarification on identities involved in IKEv2EAPauthentication
Yoav Nir writes: Since the gateway acts as a pass-through, the requirement here is more for the client, which is typically more integrated. The client should be prepared to give an identity hint both in IKE and later in the EAP session. And in that case the identities should really be same, and if they differ then the authenticated identity needs to be used for policy lookups, meaning that the EAP identity needs to be used. So the gateway needs to get that authenticated identity from the AAA server so it can do policy lookups based on it. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] comments on esp-null-heuristics-01
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As end nodes might be able to bypass those checks by using encrypted ESP instead of ESP-NULL, these kinds of scenarios also require very specific policies to forbid such circumvention. The question is, are these end-nodes malicious, or are they just ignorant? Because the traffic inspected is usually host to host traffic inside one organization, that usually means transport mode IPsec is used. It is? I'll bet 95% of actual transport mode IPsec has an L2TP layer inside. === I agree with the analysis of section 3, in particular the explanation of how hardware can be programmed to statefully match the ESP-NULL flows. It might be worth noting that NAT-T ESP-NULL flows *ALREADY* have a 5-tuple (likely unique) marker, and that if the inspector is also a NA(P)T, that it already is keeping the right state. section 4. It might be worth having a reference for flow cache. I think that there is a document on Cisco Netflow, and I also think that FORCES has something that relates to the Linux flow things. I think it might also be worth staying that this is really a microflow cache. Include a forward reference to section 7, so the reader knows UDP will be dealt with. In particular, in the text relating to NAT-T encapsulated IKE packets. If they are not allowed through (queue until sure, or drop option), then the SA might not get setup ever.. section 8.2 I'd rather see the math/calculations in a display... that would eliminate the difficulty in reading when things are wrapped. page 16: those cases the packet must be marked unsure. s/must/MUST/ ??? I have read the appendix code, and I do not see anything glaringly out at me, but I'd have to sit down and actually implement to know if all the situations are taken care of. It seems like good guidance, and the statements in the Appendix were familiar from reading the text. In conclusion: while I think the whole inspection notion is ridiculous, and likely is going to get in the way of deployment of new protocols, and may well help the throttlers (cf. Mark Handley's Net Neutrality presentation at IETF75), I find that if the inspection people follow the very sage advice of Kivinen and McDonald, that the least amount of harm possible will be done. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSvGXlICLcPvd0N1lAQIQ+Af/ViKcqG7Ed9CLVzXbiZOUGUArYJizkO5t teH+U6DuvPmfX2yLr4cZhEcH5CmhfF6xh2Y2Lg3yc5+IGjk2pqzwn6eRONfP1bwO 8LcFZQ+a215sVCHoFDNFhMzyyMi6i2F/wiyNnSpfEG3HX3gvjonkZJcWKxm6lbyr uNNPs2BrC11OQcqGsyVXqH1C2T5c42cdauh/Z3U7hxflyf/WNFU3iux3I8SgmgWx QkZBwp8U60ugbuN/LuA3O72+XXChfQPQppR50aX1RLS86D5UmJoyJvsuA0XOfLSg qS9H+RWMRk4RgLiO4DrlwhYVoKznhwf48XTaCTa8nPT+rT2ffLzepA== =H/OJ -END PGP SIGNATURE- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
Scott, From: ipsec-boun...@ietf.org On Behalf Of Scott C Moonen Sent: Thursday, November 12, 2009 2.37 AM To: Jack Kohn Cc: ipsec@ietf.org; ipsec-boun...@ietf.org Subject: Re: [IPsec] WESP - Roadmap Ahead Jack, I'm not sure it's clear yet whether WESP will be widely adopted. There's disagreement between end-node and middle-node folks as to whether WESP or heuristics are the best approach for inspection of ESP-NULL traffic. I think that end-node vendors will be very reluctant to adopt I cant comment on the interest of the end-node vendors, but i can certainly say that this will be of interest to the router vendors. There are currently a lot of applications (routing/signaling for instance) where we use ESP-NULL for integrity protection (confidentiality is not an issue there) and it will be really good if there are ways to deep inspect these packets for proper QoS treatment. WESP widely until there is broad customer demand for it, and I'm not sure that this demand will ever materialize. This is all my personal opinion, of course. But it seems to me that heuristics will have to be adopted by competitive middle-node vendors, and therefore (barring any extensions to WESP that make it attractive for other reasons) the use of heuristics will probably always be more widespread and will dampen the demand for WESP. Additionally, There you go: http://tools.ietf.org/html/draft-montenegro-ipsecme-wesp-extensions-00 ESP-NULL itself has rather narrow applicability in an environment where end-to-end encryption is increasingly common, which further limits Most routing, signaling protocols use ESP-NULL (it's a MUST, while support for AH is a MAY) and I can see benefits of moving to WESP from the QoS perspective. I am not saying that we cannot do QoS with ESP, but it just becomes a tad more flexible/easier with WESP. the cases where there will be an absolute need for WESP. Furthermore, there will always be valid reasons to use AH (reduced overhead compared to WESP). For reasons like these, I believe it's premature to call for deprecation of AH and even more premature to start preferring WESP to ESP. I agree. What status will the WESP RFC have? Experimental, informational, standards track, etc.? Standards Track Cheers, Manav Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen http://www.linkedin.com/in/smoonen ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
Steve, I would have no problem deprecating AH in the context of the IPsec architecture document, if others agree. It is less efficient than ESP-NULL. However, other WGs have cited AH as the IPsec protocol of choice for integrity/authentication in their environments, so there will be a need to coordinate with them, and it may be unacceptable to kill AH as a standalone protocol for them. I agree that it is a trifle too early to start deprecating AH, though I wouldn't mind doing so. OTOH, don't most WGs already suggest AH as a MAY, and ESP-NULL as a MUST? In any case what should be the stand for the newer work that comes out of these WGs. Should they spell out support for AH, or should they just be talking about ESP (or ESP-NULL or WESP)? If we want to deprecate AH, or at least discourage its use in the context of the IPSec architecture in the near future then shouldn't we be working on this? I am not comfortable with the notion of ESP with WESP. WESP adds more per-packet overhead than ESP, and some users are very sensitive to this aspect of IPsec use. Also, other WG rely on ESP and we would need to convince them that the packet inspection features of WESP merit making changes to their standards, which might be a tough sell. I agree. However, we should start socializing WESP in other WGs so that folks are at least aware of it. Cheers, Manav So, I cannot support this suggestion. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Finishing #22 (was: Re: Closing the IKEv2bis open issues)
Title: Finishing #22 (was: Re: [IPsec] Closing the IKEv2bis open Resent so that the issue number is in subject line only. Please reply to this thread. At 11:42 AM -0800 11/11/09, Keith Welter wrote: Issue #22, Add section on simultaneous IKE SA rekey http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/22 There is no consensus on this issue. Tero Kivinen and David Wierbowski have deep differences of opinion, and almost no one else has participated. I have reviewed the discussion, and I think both people have strong merits to their opinion. Therefore, Yaron and I will try to coordinate a design team effort that includes Tero, David, and any others who have thought about this issue in depth. If that fails to come out with an agreed-to solution, we will probably drop back to adding a short, inconclusive, descriptive note in the IKEv2bis document. A design team was convened including Dan McDonald, Tero Kivinen, Raj Singh, David Wierbowski and Keith Welter to resolve Issue #22. The design team reached agreement on the following general approach as well as specific proposed text: - Import text from RFC 4718 section 5.11.10 into new ikev2biz draft section 2.25 Exchange Collisions - Replace NO_PROPOSAL_CHOSEN and NO_ADDITIONAL_SAS with new TEMPORARY_FAILURE error type notify. - Add new CHILD_SA_NOT_FOUND error type notify for one collision case. - Add text in new section 2.25 describing what to do when the new notify types are received. The proposed text that follows includes a new section and updates to existing sections for ikev2bis. 2.25 Exchange Collisions (New Section) Since IKEv2 exchanges can be initiated by both peers, it is possible that two exchanges affecting the same SA partly overlap. This can lead to a situation where the SA state information is temporarily not synchronized, and a peer can receive a request it cannot process in a normal fashion. Obviously, using a window size greater than one leads to more complex situations, especially if requests are processed out of order. In this section, we concentrate on problems that can arise even with window size 1 and recommend solutions. A TEMPORARY_FAILURE notification SHOULD be sent when a host receives a request that cannot be completed due to a temporary condition such as a rekeying operation. When a host receives a TEMPORARY_FAILURE notification, it MUST NOT immediately retry the operation but wait so that the sender may complete whatever operation caused the temporary condition. The recipient MAY retry the request one or more times over a period of several minutes. If a host continues to receive TEMPORARY_FAILURE on the same IKE SA after several minutes then it SHOULD conclude that state information is out-of-sync and close the IKE SA. A CHILD_SA_NOT_FOUND notification SHOULD be sent when a host receives a request to rekey a Child SA that does not exist. A host that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA and send a request to create a new Child SA from scratch. If a host receives a request to rekey: o a Child SA that the host is currently trying to close: reply with TEMPORARY_FAILURE. o a Child SA that the host is currently rekeying: reply as usual, but prepare to close redundant SAs later based on the nonces. o a Child SA that does not exist: reply with CHILD_SA_NOT_FOUND. o the IKE SA, and the host is currently rekeying the IKE SA: reply as usual, but prepare to close redundant SAs and move inherited Child SAs later based on the nonces. o the IKE SA, and the host is currently creating, rekeying, or closing a Child SA: reply with TEMPORARY_FAILURE. o the IKE SA, and the host is currently trying to close the IKE SA: reply with TEMPORARY_FAILURE. If a host receives a request to close: o a Child SA that the host is currently trying to close: reply without Delete payloads. o a Child SA that the host is currently rekeying: reply as usual, with Delete payload. o a Child SA that does not exist: reply without Delete payloads. o the IKE SA, and the host is currently rekeying the IKE SA: reply as usual, and forget about our own rekeying request. o the IKE SA, and the host is currently trying to close the IKE SA: reply as usual, and forget about our own close request. If a host receives a request to create or rekey a CHILD_SA when it is currently rekeying the IKE_SA: reply with TEMPORARY_FAILURE. If a host receives a request to delete a Child SA when it is currently rekeying the IKE SA: reply as usual, with Delete payload. 3.10.1. Notify Message Types (Updates) ... NOTIFY messages: error types Value --- ... TEMPORARY_FAILURE 40 See section 2.25. CHILD_SA_NOT_FOUND 41 See section 2.25. RESERVED TO IANA 42-8191 ... 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange (Updates) Add the following sentence to the end of the first paragraph of section 1.3.2: Once a host receives a request to rekey an IKE SA or sends a
Re: [IPsec] WESP - Roadmap Ahead
At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote: Steve, I would have no problem deprecating AH in the context of the IPsec architecture document, if others agree. It is less efficient than ESP-NULL. However, other WGs have cited AH as the IPsec protocol of choice for integrity/authentication in their environments, so there will be a need to coordinate with them, and it may be unacceptable to kill AH as a standalone protocol for them. I agree that it is a trifle too early to start deprecating AH, though I wouldn't mind doing so. OTOH, don't most WGs already suggest AH as a MAY, and ESP-NULL as a MUST? Not always. For example, I believe that OSPF security makes use of AH, outside the IPsec context. In any case what should be the stand for the newer work that comes out of these WGs. Should they spell out support for AH, or should they just be talking about ESP (or ESP-NULL or WESP)? I'd recommend ESP-NULL, unless the context on which the operate might require inspection by an intermediate system. If we want to deprecate AH, or at least discourage its use in the context of the IPSec architecture in the near future then shouldn't we be working on this? Part of the problem is that some WGs want to make use of IPsec protocols outside of the IPsec architecture. I am not comfortable with the notion of ESP with WESP. WESP adds more per-packet overhead than ESP, and some users are very sensitive to this aspect of IPsec use. Also, other WG rely on ESP and we would need to convince them that the packet inspection features of WESP merit making changes to their standards, which might be a tough sell. I agree. However, we should start socializing WESP in other WGs so that folks are at least aware of it. Agree. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
All of the standards I've seen that explicitly define how IPsec is to be used for authentication (including RFC 4552 - Authentication/ Confidentiality for OSPFv3) say that for authentication ESP-Null MUST be used and AH MAY. Yes, this is correct. The latest PIM-SM authentication document (http://tools.ietf.org/html/draft-ietf-pim-sm-linklocal-08) uses IPSec to authenticate link-local messages in PIM-SM. It too says that ESP is a MUST while use of AH is optional. Which RFCs specify AH specifically as a MUST for authentication/ integrity? I am not aware of any that do that. Now on the flip side, in practical implementations, most vendors I know of started off with AH being used for OSPFv3 and I doubt in practice people are using ESP-Null. Would love to be wrong here :) I don't think this is really true. I know of at least two major vendors that use ESP-NULL and one of them doesn't even support AH. Cheers, Manav - merike On Nov 11, 2009, at 7:28 PM, Stephen Kent wrote: At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote: Steve, I would have no problem deprecating AH in the context of the IPsec architecture document, if others agree. It is less efficient than ESP-NULL. However, other WGs have cited AH as the IPsec protocol of choice for integrity/authentication in their environments, so there will be a need to coordinate with them, and it may be unacceptable to kill AH as a standalone protocol for them. I agree that it is a trifle too early to start deprecating AH, though I wouldn't mind doing so. OTOH, don't most WGs already suggest AH as a MAY, and ESP-NULL as a MUST? Not always. For example, I believe that OSPF security makes use of AH, outside the IPsec context. In any case what should be the stand for the newer work that comes out of these WGs. Should they spell out support for AH, or should they just be talking about ESP (or ESP-NULL or WESP)? I'd recommend ESP-NULL, unless the context on which the operate might require inspection by an intermediate system. If we want to deprecate AH, or at least discourage its use in the context of the IPSec architecture in the near future then shouldn't we be working on this? Part of the problem is that some WGs want to make use of IPsec protocols outside of the IPsec architecture. I am not comfortable with the notion of ESP with WESP. WESP adds more per-packet overhead than ESP, and some users are very sensitive to this aspect of IPsec use. Also, other WG rely on ESP and we would need to convince them that the packet inspection features of WESP merit making changes to their standards, which might be a tough sell. I agree. However, we should start socializing WESP in other WGs so that folks are at least aware of it. Agree. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although they never refer to it that way) as a MUST, and AH as a MAY. Ok, so can we work on deprecating AH? This way new standards defined in other WGs dont have to provide support for AH. Jack I probably was confused because the authors did not understand the IPsec model as per RFC 4301, when I sat down and talked with them over 3 years ago, with Sam Hartman in his SEC AD role. I am amazed that, in the final analysis, they did try to adhere to the 4301 model (see section 11)! I don't know if any other apps have done what I thought (erroneously) had been done here. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME WG report
IPsecME met this morning. We have one RFC (IKEv2 Redirect) recently published, and a couple more in the RFC Editor queue. The other small drafts are coming along as well. The group is making progress on IKEv2-bis, and we had a presentation on one thorny protocol issue that was resolved by a design team. Our goal is to move it out of the WG *before* the next F2F meeting. The bulk of the meeting was presentation of 7 candidate work items. The group was polled for volunteer reviewers and contributors for each of these. This process will continue on the mailing list, and eventually we will propose a new charter, retaining the number of concurrent work items. On the process side, we had one presenter on an audio bridge - which worked fine - and another as a prerecorded podcast, which also worked after some technical fumbling. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
All of the standards I've seen that explicitly define how IPsec is to be used for authentication (including RFC 4552 - Authentication/ Confidentiality for OSPFv3) say that for authentication ESP-Null MUST be used and AH MAY. Which RFCs specify AH specifically as a MUST for authentication/ integrity? Now on the flip side, in practical implementations, most vendors I know of started off with AH being used for OSPFv3 and I doubt in practice people are using ESP-Null. Would love to be wrong here :) - merike On Nov 11, 2009, at 7:28 PM, Stephen Kent wrote: At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote: Steve, I would have no problem deprecating AH in the context of the IPsec architecture document, if others agree. It is less efficient than ESP-NULL. However, other WGs have cited AH as the IPsec protocol of choice for integrity/authentication in their environments, so there will be a need to coordinate with them, and it may be unacceptable to kill AH as a standalone protocol for them. I agree that it is a trifle too early to start deprecating AH, though I wouldn't mind doing so. OTOH, don't most WGs already suggest AH as a MAY, and ESP-NULL as a MUST? Not always. For example, I believe that OSPF security makes use of AH, outside the IPsec context. In any case what should be the stand for the newer work that comes out of these WGs. Should they spell out support for AH, or should they just be talking about ESP (or ESP-NULL or WESP)? I'd recommend ESP-NULL, unless the context on which the operate might require inspection by an intermediate system. If we want to deprecate AH, or at least discourage its use in the context of the IPSec architecture in the near future then shouldn't we be working on this? Part of the problem is that some WGs want to make use of IPsec protocols outside of the IPsec architecture. I am not comfortable with the notion of ESP with WESP. WESP adds more per-packet overhead than ESP, and some users are very sensitive to this aspect of IPsec use. Also, other WG rely on ESP and we would need to convince them that the packet inspection features of WESP merit making changes to their standards, which might be a tough sell. I agree. However, we should start socializing WESP in other WGs so that folks are at least aware of it. Agree. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WESP - Roadmap Ahead
On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn kohn.j...@gmail.com wrote: Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although they never refer to it that way) as a MUST, and AH as a MAY. Ok, so can we work on deprecating AH? This way new standards defined in other WGs dont have to provide support for AH. AH is a security feature we need to keep for header authentication. Other WG may chose not to deal with AH and only consider ESP. I don't see what's wrong with that? Regards Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
