Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[david.black]

> I think "IETF Review" would be good compromise for this as it would
> make it easier than "Standard Track RFC", but would satisfy those who
> do not want to have it as lower as "Specification Required" is...

Summarizing my views:
- "Specification Required" is an unacceptably low bar for this sort of
security protocol due to the possibility of security flaws.
- I prefer "IETF Review" to "Expert Review" for this sort of security
protocol as "IETF Review" should yield higher-quality results.

Thanks,
--David

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> Tero Kivinen
> Sent: Wednesday, March 28, 2012 9:04 AM
> To: Dan Harkins
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods 
> (Value 3) registration
> policy
> 
> Dan Harkins writes:
> >   We can't always get what we want and we should be reasonable in
> > understanding that. If we could wave a magic wand and grant your wish
> > that would be good; we can't. And given the limits to our power we
> > have to accept that what will happen is people will continue to use
> > IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too
> > much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK
> > though, so it is likely that by adding SPSK to IKEv1 we could get people
> > off of XAUTH and that too would be a good thing.
> >
> >   So if we weigh the improbable stretch goal of forcing people to stop
> > using IKEv1 with the probable, more easily attainable, goal of getting
> > people to stop using XAUTH by giving them an alternative that can pretty
> > easily be implemented, I still come down on settling for an achievable
> > goal of goodness and not making that be a victim for an unachievable goal
> > of betterness.
> 
> The reason they cannot move to use IKEv1 + SPSK any faster than they
> can move to use IKEv2 + SPSK is same. Both of them do require new
> version of both client and server. The client customers always tell
> that the reason they cannot use IKEv2 as the SGW's they use do not
> support IKEv2 (or it is not turned on by default). The SGW customers
> say that the reason they cannot use IKEv2 as they clients do not
> support it (or it is not turned on by default)...
> 
> > > Regardless whether it is Specification Required or not, I am still
> > > objecting if someone tries to add new features to IKEv1. Of course my
> > > objecting might not have any effect, but I still think it is BAD idea.
> >
> >   OK, so we're in agreement: "Specification Required."
> 
> I originally suggested "Specification Required", so yes we are in
> agreement in that, but we are not only people in the WG, and there has
> been people saying otherwise. If we do not reach some kind of
> concensus, then the default action will most likely be "do nothing",
> which will mean the registry stays what it is now, and I do not want
> that.
> 
> I think "IETF Review" would be good compromise for this as it would
> make it easier than "Standard Track RFC", but would satisfy those who
> do not want to have it as lower as "Specification Required" is...
> --
> kivi...@iki.fi
> ___
> 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] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[david.black]

>   I think we can make things better with a simple addition and I just
> want to be able to do that.

To ask bluntly - what is the problem with soliciting AD sponsorship for the 
simple addition?

IMHO, "Specification Required" by itself is entirely too weak for security 
protocols.

Thanks,
--David

> -Original Message-
> From: Dan Harkins [mailto:dhark...@lounge.org]
> Sent: Tuesday, March 27, 2012 12:23 PM
> To: Black, David
> Cc: dhark...@lounge.org; kivi...@iki.fi; ipsec@ietf.org
> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods 
> (Value 3) registration
> policy
> 
> 
>   Hi David,
> 
> On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote:
> > Hi Dan,
> >
> > One process note:
> >
> >>   It appears that all the PAKE drafts got one "yes" from the sponsoring
> >> AD and the remaining votes were "no objection" so it doesn't seem like
> >> the IESG is really interested in this topic and, frankly, I think the
> >> majority think "that stuff is out of my field of expertise". So my only
> >> option is to cajole an AD into sponsoring my draft and hoping that no
> >> one
> >> else on the IESG objects by saying, "didn't we just do this?"
> >
> > Speaking from long experience as a chair of many WGs, that sort of IESG
> > vote tally is typical, even for WG docs (although usually both of the
> > responsible Area ADs vote yes, as they're both "sponsoring").  IMHO,
> > you're being overly pessimistic.
> >
> >>   So let me turn it around, what's wrong with "Specification Required"?
> >
> > While I know that you're competent to design a solid  protocol, who does
> > the security review of the next 5 j-random authentication mechanisms to
> > make sure that they don't have security flaws?  I'd prefer something like
> > IESG approval that puts the Security Area in the loop to the notion of
> > deferring to some form of Expert Review (this is not a slam against Tero
> > as the expert - wider review usually produces better results).
> 
>   That's a really good point. Had it been "Specification Required" all
> along XAUTH might've gotten an official code point. And who knows maybe
> one of the j-random proposals might be just that. But IKEv1 really is
> pretty done. At this point I'm pretty sure that j would be zero.
> 
>   I know IKE's being used wrong and I know the people who are using it
> wrong don't want to go to IKEv2. They understand what they're doing is
> broken (a shared PSK for everyone followed by PAP in XAUTH) but they
> don't want to go to IKEv2 and use EAP to "fix" it, and it doesn't sound
> like going to IKEv2 with SPSK is much more attractive.
> 
>   I think we can make things better with a simple addition and I just
> want to be able to do that.
> 
>   regards,
> 
>   Dan.
> 
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

[david.black]

Hi Dan,

One process note:

>   It appears that all the PAKE drafts got one "yes" from the sponsoring
> AD and the remaining votes were "no objection" so it doesn't seem like
> the IESG is really interested in this topic and, frankly, I think the
> majority think "that stuff is out of my field of expertise". So my only
> option is to cajole an AD into sponsoring my draft and hoping that no one
> else on the IESG objects by saying, "didn't we just do this?"

Speaking from long experience as a chair of many WGs, that sort of IESG vote 
tally is typical, even for WG docs (although usually both of the responsible 
Area ADs vote yes, as they're both "sponsoring").  IMHO, you're being overly 
pessimistic.

>   So let me turn it around, what's wrong with "Specification Required"?

While I know that you're competent to design a solid  protocol, who does the 
security review of the next 5 j-random authentication mechanisms to make sure 
that they don't have security flaws?  I'd prefer something like IESG approval 
that puts the Security Area in the loop to the notion of deferring to some form 
of Expert Review (this is not a slam against Tero as the expert - wider review 
usually produces better results).

Thanks,
--David


> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan 
> Harkins
> Sent: Tuesday, March 27, 2012 10:14 AM
> To: Tero Kivinen
> Cc: ipsec@ietf.org; Dan Harkins
> Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods 
> (Value 3) registration
> policy
> 
> 
> On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote:
> > Dan Harkins writes:
> >>   I guess I'd like to register an objection. I wrote a draft a few
> >> months
> >> ago to address this:
> >>
> >>  http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt
> >>
> >> That suggested making it "Specification Required". You mentioned that
> >> someone was opposed to it being "Specification Required" but didn't say
> >> who or what the rationale was behind that opposition.
> >>
> >>   So I'd like to discuss this a bit. I prefer "Specification Required"
> >> and would like to know what the problem someone has with it is.
> >
> > See the orignal thread in the ipsec-list:
> >
> > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html
> 
>   OK, but that says "'Specification Required' or 'IETF Review'", it's
> not opposition to "Specification Required".
> 
> > What is your objection to the IETF Review?
> 
>   Well, I feel it is setting the bar too high for what I want to do.
> I had to remove a chunk of text from my PAKE draft fixed a significant,
> know, serious, and continuing problem with IKEv1. I was told that
> I should write another I-D that includes that text and try to see
> what happens. The issue is that requiring IESG review and AD sponsorship
> will likely result in me not getting over that bar and getting a code
> point assigned.
> 
>   It appears that all the PAKE drafts got one "yes" from the sponsoring
> AD and the remaining votes were "no objection" so it doesn't seem like
> the IESG is really interested in this topic and, frankly, I think the
> majority think "that stuff is out of my field of expertise". So my only
> option is to cajole an AD into sponsoring my draft and hoping that no one
> else on the IESG objects by saying, "didn't we just do this?"
> 
>   I don't want to burn up what remaining goodwill I might have with
> our ADs by continuing to push this topic.
> 
>   That said, the problem I want to fix-- IKEv1's susceptibility to
> dictionary attack, it's binding of a PSK to an IP address, and the
> prevalence of XAUTH because there's no other option-- should be fixed.
> We can say, "stop using IKEv1" but giving someone the option of
> implementing PAKE + IKEv2 versus just implementing PAKE, or more likely
> just continuing on with a broken XAUTH deployment, we all know what
> they'll do and it's not doing PAKE + IKEv2. It would be a service to
> the Internet to provide a fix for this. The IETF has not been successful
> in forcing people to do things against their will (viz, the history of
> IPv6) and if we tried here we'd likely fail again.
> 
>   So let me turn it around, what's wrong with "Specification Required"?
> 
>   thanks,
> 
>   Dan.
> 
> >> >   IETF Review - (Formerly called "IETF Consensus" in
> >> > [IANA-CONSIDERATIONS]) New values are assigned only
> >> through
> >> > RFCs that have been shepherded through the IESG as AD-
> >> > Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
> >> > intention is that the document and proposed assignment
> >> will
> >> > be reviewed by the IESG and appropriate IETF WGs (or
> >> > experts, if suitable working groups no longer exist) to
> >> > ensure that the proposed assignment will not negatively
> >> > impact interoperability or otherwise extend IETF protocols
> >> > in

Re: [IPsec] Moving Authentication Header (AH) to Historic

[david.black]

Hi Manav,

I think it's more important to clearly state what we want protocol designers to 
do/not do and why (ditto for IPsec implementers).  We can figure out the 
process stuff later.  I definitely think that it's worth spending time on 
drafting guidance about when (if ever) use of AH in new protocols is 
appropriate.

Thanks, --David +++ Sent from BlackBerry +++

- Original Message -
From: Bhatia, Manav (Manav) [mailto:manav.bha...@alcatel-lucent.com]
Sent: Saturday, December 31, 2011 08:53 PM
To: Black, David; yaronf.i...@gmail.com 
Cc: ipsec@ietf.org 
Subject: RE: Moving Authentication Header (AH) to Historic

Hi David and Yaron,

I think its possible to edit the draft headers and the text so that we 
basically say that AH should NOT be used for newer proposals unless there is a 
burning reason to do so. And if someone wants to use AH, then they should have 
a pretty good reason for doing that. In my draft I clearly say that AH does a 
good job with whats its supposed to do - integrity verification. However, 
ESP-NULL does that equally good and there is no good reason to use AH any more. 
I wrote this draft because I was having a private discussion on PIM security 
with a few folks and the discussion started veering towards "Hey lets use AH 
since we want to snoop certain PIM packets and ESP-NULL wouldn’t let us do 
that". 

So, while people working on security understand that AH should not be used for 
newer protocols, there are lots of others who don’t.

I just wanted that to be pointed out explicitly. 

I don’t really care whether its through an informational RFC, BCP, standards 
track or some other type as long as the message is out loud and clear. However, 
before spending any more cycles on it I would first like to gauge the interest 
level in the WG to see if people think it’s an idea worth spending time on. And 
if not, then why.

Cheers, Manav

-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
david.bl...@emc.com
Sent: Sunday, January 01, 2012 6:59 AM
To: yaronf.i...@gmail.com
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic

> I spent a few minutes trying to look up the precise definition of 
> "Historic Documents" in the IETF standards process. Since the 
> definition appears to be extremely vague and may not clearly apply in 
> this case,

FWIW, the definition of "Historic" is in RFC 2026, and I agree with Yaron that 
it's not exactly precise:

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.  (Purists have suggested that the
   word should be "Historical"; however, at this point the use of
   "Historic" is historical.)

There is a subtle distinction between Obsolete and Historic - an Historic RFC 
is always Obsolete, but an Obsolete RFC may not be Historic.  Before going any 
further,  let me say that I strongly agree with Yaron on priorities:

> I strongly suggest that we avoid this rathole (and move to the next 
> one), by adopting the proposed wording below. Manav's I-D is an 
> Independent document and so its content is completely up to its 
> author; OTOH, I'd rather not waste the group's energy on 
> not-very-important process matters. What does matter is that 
> implementers and standards bodies understand the strengths and weaknesses of 
> our protocols.

In order to obsolete AH, the draft header needs to say "Obsoletes: 4302", in 
addition to its discussion of making RFC 4302 Historic.  Both of the foregoing 
require that the draft not be Informational; I'd go further and suggest that 
with suitable editing and review, this could be a Best Current Practice (BCP) 
RFC, as the primary goal is to document the following as current design 
practice:

> > "AH should not be
> > preferred when designing new protocols and all attempts must be made 
> > to use ESP-NULL"

I believe that a BCP can be used to cause a standards track RFC to become 
obsolete.

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com    Mobile: +1 (978) 394-7754


> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf 
> Of Yaron Sheffer
> Sent: Saturday, December 31, 2011 2:26 PM
> To: Dacheng Zhang(Dacheng)
> Cc: ipsec@ietf.org; Melinda Shore; Yoav Nir; Jack Kohn
> Subject: Re: [IPsec] 答复: Moving Authentication Header (AH) to Historic
> 
> I agree that people should prefer ESP-null for all new uses.
> 
> I spent a few minutes trying to look up the precise definition of 
> "Historic Documents" in the IETF standards process. Since the 
> definition appears to be extremely vague and may not clearly apply in 
> this case, 

Re: [IPsec] Moving Authentication Header (AH) to Historic

[david.black]

> I spent a few minutes trying to look up the precise definition of
> "Historic Documents" in the IETF standards process. Since the definition
> appears to be extremely vague and may not clearly apply in this case,

FWIW, the definition of "Historic" is in RFC 2026, and I agree with Yaron that
it's not exactly precise:

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.  (Purists have suggested that the
   word should be "Historical"; however, at this point the use of
   "Historic" is historical.)

There is a subtle distinction between Obsolete and Historic - an Historic RFC
is always Obsolete, but an Obsolete RFC may not be Historic.  Before going any
further,  let me say that I strongly agree with Yaron on priorities:

> I strongly suggest that we avoid this rathole (and move to the next one),
> by adopting the proposed wording below. Manav's I-D is an Independent
> document and so its content is completely up to its author; OTOH, I'd
> rather not waste the group's energy on not-very-important process
> matters. What does matter is that implementers and standards bodies
> understand the strengths and weaknesses of our protocols.  

In order to obsolete AH, the draft header needs to say "Obsoletes: 4302", in
addition to its discussion of making RFC 4302 Historic.  Both of the foregoing
require that the draft not be Informational; I'd go further and suggest that 
with
suitable editing and review, this could be a Best Current Practice (BCP) RFC,
as the primary goal is to document the following as current design practice:

> > "AH should not be
> > preferred when designing new protocols and all attempts must be made
> > to use ESP-NULL"

I believe that a BCP can be used to cause a standards track RFC to become
obsolete.

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com    Mobile: +1 (978) 394-7754


> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> Yaron Sheffer
> Sent: Saturday, December 31, 2011 2:26 PM
> To: Dacheng Zhang(Dacheng)
> Cc: ipsec@ietf.org; Melinda Shore; Yoav Nir; Jack Kohn
> Subject: Re: [IPsec] 答复: Moving Authentication Header (AH) to Historic
> 
> I agree that people should prefer ESP-null for all new uses.
> 
> I spent a few minutes trying to look up the precise definition of
> "Historic Documents" in the IETF standards process. Since the definition
> appears to be extremely vague and may not clearly apply in this case, I
> strongly suggest that we avoid this rathole (and move to the next one),
> by adopting the proposed wording below. Manav's I-D is an Independent
> document and so its content is completely up to its author; OTOH, I'd
> rather not waste the group's energy on not-very-important process
> matters. What does matter is that implementers and standards bodies
> understand the strengths and weaknesses of our protocols.
> 
> Wishing us all a Happy New Year 2012!
> 
>  Yaron
> 
> On 12/31/2011 05:58 AM, Dacheng Zhang(Dacheng) wrote:
> >>> If folks dont want to move AH to historic then perhaps this document
> >>> could be modified to say something in the lines of - "AH should not be
> >>> preferred when designing new protocols and all attempts must be made
> >>> to use ESP-NULL"
> > [Dacheng Zhang]
> > Really like this suggestion. +1
> >>> Jack
> > ___
> > 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 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Large Scale VPN

[david.black]

+1, Thanks, --David

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> Stephen Hanna
> Sent: Monday, December 12, 2011 10:19 AM
> To: Yoav Nir; IPsecme WG
> Cc: Paul Hoffman
> Subject: Re: [IPsec] Large Scale VPN
> 
> Yes, I definitely think this is a good idea.
> 
> Thanks,
> 
> Steve
> 
> > -Original Message-
> > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> > Of Yoav Nir
> > Sent: Monday, December 12, 2011 4:45 AM
> > To: IPsecme WG
> > Cc: Paul Hoffman
> > Subject: Re: [IPsec] Large Scale VPN
> >
> > Hi all
> >
> > If we want Paul and Yaron to take this to our AD, we need to show that
> > there are more people who think these work items are a good idea. More
> > people than just me and MCR.  So please show your support (or
> > objections!) soon. An "I think this is a good idea", "I think we should
> > use ternary logic", or "+1" is all it takes.
> >
> > Yoav
> >
> > On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote:
> > >
> > > Agree. How about:
> > >
> > > In an environment with many IPsec gateways and remote clients that
> > share an established trust infrastructure (in a single administrative
> > domain or across multiple domains), customers want to get on-demand
> > point-to-point IPsec capability for efficiency. However, this cannot be
> > feasibly accomplished only with today's IPsec and IKE due to problems
> > with address lookup, reachability, policy configuration, etc.
> > >
> > > The IPsecME working group will handle this large scale VPN problem by
> > delivering the following:
> > >
> > > * The working group will create a problem statement document
> > including use cases, definitions and proper requirements for discovery
> > and updates. This document would be solution-agnostic. Should reach WG
> > last call around October 2012.
> > >
> > > * The working group will review and help publish Informational
> > documents describing current vendor proprietary solutions. These should
> > be ready for IETF last call by August 2012.
> > >
> > > * The working group will choose a common solution for the discovery
> > and update problems that will satisfy the requirements in the problem
> > statement document. The working group may standardize one of the vendor
> > solutions, a combination, an superset of such a solution, or a new
> > protocol.
> >
> > ___
> > 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 mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] iSCSI: IPsec requirements

[david.black]

Michael,

Thanks for the response.

iSCSI is a rather stable protocol - existing implementations are expected to 
comply with this new spec with little to no change.  There is another draft in 
the storm WG that is making minor functional additions to iSCSI (given the 
number of years since RFC 3720, the amount of change needed is surprisingly 
small).

The new spec needs to normatively reference and update RFC 3723 (but there will 
be no 3723bis), so it sounds like the right approach is the following 
combination:

- MUST implement IPsec, 2400-series RFCs (IPsec v2, IKEv1).
- SHOULD implement IPsec, 4300-series RFCs (IPsec v3, IKEv2).

The MUST is for interoperability and to acknowledge what's out there; the 
SHOULD is to encourage implementers to move forward.  Now I need to go write 
the actual text to go into the draft.

Thanks,
--David

> -Original Message-
> From: m...@sandelman.ca [mailto:m...@sandelman.ca]
> Sent: Tuesday, October 11, 2011 9:42 PM
> To: Black, David
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] iSCSI: IPsec requirements
> 
> 
> > "david" == david black  writes:
> david> Assuming 2400-series IPsec is not extinct, the appropriate 
> requirements may be of
> david> roughly the following form (this is a template, see RFC 3720
> david> or 3723 for the specific
> 
> Well, I'm not really sure how to answer your question.
> There is certainly still lots and lots and lots of 2400-series IPsec in
> use.  I'd say it was the majority in devices which can easily be
> upgraded, and which aren't because IKEv1 still works well for the
> solution space out there.  Certainly IKEv2 is pretty rare on
> smartphones, I'd say for *VPN* connectivity.
> While at the same time, it's required for 3GPP interop (my
> understanding, I never wrote that code myself)
> 
> However, we aren't talking about general purpose devices, but rather
> operating systems, HBA cards, virtualization systems (iSCSI clients) and
> NAS (iSCSI targets).
> 
> Presuming that none of these devices is going to want to stop claiming
> conformance to RFC 3723/RFC 3720, then they will have to continue to
> implement IPsec-2400 series.
> 
> The only advantage to implementing IPsec-4300 series would be on newer
> devices where code space and configuration is an issue, i.e. HBAs.
> It isn't like an IKEv2 speaking endpoint can't recognize and speak
> IKEv1, particularly when it is a responder, it doesn't even cost a round
> trip.
> 
> I don't know what other things you are updating in this round, so I
> don't know what other things might drive an implementation to do
> RFC3720bis,  but would prevent it from deploying IKEv2.
> 
> I therefore think that you should MUST implement 4300 (IKEv2), and MAY
> implement 2400 series (IKEv1).  Note that the *ESP* level things, like
> extended sequence numbers that appears in 4300 can be negotiated, so
> it's really not that big a deal to MUST the rest of 4300 stuff in my
> opinion.
> 
> All the iSCSI devices that want to support 3723/3720 clients is going to
> support IKEv1.  But, if there is a greenfield implementation of 3720bis,
> then they could implement only the much simpler IKEv2.
> 
> 
> --
> ]   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 
>  then sign the petition.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] iSCSI: IPsec requirements

[david.black]

As a co-chair of the storm WG, I'm looking for some input on updating the IPsec
requirements for iSCSI, which is the subject of a WG Last Call comment against
the new iSCSI draft.

The history here is that as part of the original work for iSCSI (and some 
additional
storage protocols), a profile of the then-current version of IPsec (2400-series 
RFCs)
was produced (RFC 3723), and iSCSI (RFC 3720) has "MUST implement" requirements 
for
that version of IPsec.  By the time iSCSI was completed, the next version of 
IPsec
(4300-series RFCs) was imminent, but a deliberate decision was made to have both
RFC 3720 and 3723 continue to refer to the older version of IPsec.

A primary reason at the time was that iSCSI and IPsec implementations are 
generally
independent, and the most likely implementation path for iSCSI involved existing
older IPsec implementations.  That was back in 2004, and the IPsec world has 
moved
on since them.  The issue has been raised that it may not be appropriate for 
the new
iSCSI RFC-to-be to continue to require implementation of RFC 2400-series IPsec.

The new iSCSI draft is fully backwards compatible with the existing iSCSI RFCs 
(in
contrast to IPsec, where the versions of IKE deliberately don't interoperate), 
so
jumping straight to 4300-series IPsec does not seem like a good move unless
2400-series IPsec is extinct for all practical purposes.

Assuming 2400-series IPsec is not extinct, the appropriate requirements may be 
of
roughly the following form (this is a template, see RFC 3720 or 3723 for the 
specific
requirements to which this structure is to be applied):
- MUST implement IPsec, 2400-series RFCs or 4300-series RFCs.
- SHOULD implement IPsec, 4300-series RFCs.
- I'm not inclined to also say: SHOULD NOT implement 2400-series IPsec.

OTOH, if 2400-series IPsec is extinct for all practical purposes, that all 
reduces to
- MUST implement IPsec, 4300-series.

I'm interested in comments on what the right thing to do is here and why.

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com    Mobile: +1 (978) 394-7754


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Queries relating to ESP/AH GCM & GMAC

[david.black]

Hi Tero,

I think we're in violent agreement on:

> I am very worried when people start implementing those ciphers to
> IKEv1, as there is no way to know which features of the RFC4303 they
> decide to include too. I agree that completely removing them is not
> the way we want to go forward, but I would want to strongly recommend
> people not to add implementation for them when using IKEv1, and based
> on the text in the RFC6071 I think working group agreed on that too.

OTOH, I believe that combined-mode ciphers work fine with RFC 2406, provided
that some care is taken in the SA negotiation - the combined mode cipher is
negotiated as the encryption transform without an additional authentication
transform, and the combined mode cipher generates the ESP authentication data.

At least RFC 4106 (GCM) is clear on how to do this.

> Also RFC4309 and RFC4543 do already refer to the RFC4303 and RFC4302
> for ESP and AH, so they seem to already require ESPv3.

Not exactly - like RFC 4106 (GCM), RFC 4309 (CCM) is also written in a
fashion that works with both versions of ESP (same encapsulation as RFC
4106, but the text doesn't contain as much explanation of the details).
OTOH, use of RFC 4543 (GMAC) with IKEv1 is peculiar, as that results in
an authentication transform masquerading as an IKEv1 encryption transform,
although RFC 4543 does cite RFC 2409 (IKEv1) as usable for keying.

Nonetheless, the following is ok with me:

> I would like that recommendation to be reflected also in the IANA
> page, so implementors who just pick numbers from there would get
> warning that implementing those ciphers might not lead as good
> interoperability as they would expect compared when using IKEv2. You
> have to remember that quite of lot of implementors will simply go to
> the IANA page, pick the algorithms from there, quickly check out the
> RFCs listed there and then implement the algorithms. Many of them do
> not start looking other RFCs related to the problems, and quite many
> of them have never heard about RFC errata etc...

My objection was to the suggestion that the IANA registry entries be
removed - I have no problem discouraging use of IKEv1 in favor of
IKEv2 here and in general.

Thanks,
--David

> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Monday, April 11, 2011 9:02 AM
> To: Black, David
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC
> 
> david.bl...@emc.com writes:
> > It's more than a decision to not include that capability - IKEv1 exchanges
> > cannot be protected with combined mode algorithms without significant
> > incompatible change to IKEv1, as explained in Section 1 of RFC 5282:
> 
> That is clear, I do not think anybody even dreams using combined mode
> ciphers on IKEv1.
> 
> > OTOH, RFC 4106 (GCM), RFC 4309 (CCM), and RFC 4543 (GMAC) were written in
> > a fashion that allowed their use with ESP (RFC 2406) to be negotiated by
> > IKEv1 (and also for AH in the case of GMAC).
> 
> The problem is that combined mode ciphers are not possible to be used
> with RFC2406, as that does not support combined mode ciphers. To
> support combined mode ciphers RFC4303 is needed.
> 
> Also RFC4309 and RFC4543 do already refer to the RFC4303 and RFC4302
> for ESP and AH, so they seem to already require ESPv3.
> 
> > I would strongly object to removal of the IANA registry entries that
> > support this usage, although I agree that everyone should be using
> > IKEv2 in preference to IKEv1.
> 
> I am very worried when people start implementing those ciphers to
> IKEv1, as there is no way to know which features of the RFC4303 they
> decide to include too. I agree that completely removing them is not
> the way we want to go forward, but I would want to strongly recommend
> people not to add implementation for them when using IKEv1, and based
> on the text in the RFC6071 I think working group agreed on that too.
> 
> I would like that recommendation to be reflected also in the IANA
> page, so implementors who just pick numbers from there would get
> warning that implementing those ciphers might not lead as good
> interoperability as they would expect compared when using IKEv2. You
> have to remember that quite of lot of implementors will simply go to
> the IANA page, pick the algorithms from there, quickly check out the
> RFCs listed there and then implement the algorithms. Many of them do
> not start looking other RFCs related to the problems, and quite many
> of them have never heard about RFC errata etc...
> --
> kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Queries relating to ESP/AH GCM & GMAC

[david.black]

Here's a little more explanation of this text from RFC 6071:

>Although ESP-v2 did not originally include combined mode algorithms,
>some IKEv1 implementations have added the capability to negotiate
>combined mode algorithms for use in IPsec SAs; these implementations
>do not include the capability to use combined mode algorithms to
>protect IKE SAs.  IANA numbers for combined mode algorithms have been
>added to the IKEv1 registry.

It's more than a decision to not include that capability - IKEv1 exchanges
cannot be protected with combined mode algorithms without significant
incompatible change to IKEv1, as explained in Section 1 of RFC 5282:

   Version 1 of the Internet Key Exchange protocol (IKEv1) [RFC2409] is
   based on the Internet Security Association and Key Management
   Protocol (ISAKMP) [RFC2408].  The E (Encryption) bit in the ISAKMP
   header specifies that all payloads following the header are
   encrypted, but any data integrity verification of those payloads is
   handled by a separate Hash Payload or Signature Payload (see Sections
   3.1, 3.11, and 3.12 of [RFC2408]).  This separation of encryption
   from data integrity protection prevents the use of authenticated
   encryption with IKEv1, thus limiting initial specifications of AES
   combined mode usage for IPsec to the Encapsulating Security Payload
   (ESP) [RFC2406].

OTOH, RFC 4106 (GCM), RFC 4309 (CCM), and RFC 4543 (GMAC) were written in
a fashion that allowed their use with ESP (RFC 2406) to be negotiated by
IKEv1 (and also for AH in the case of GMAC).

I would strongly object to removal of the IANA registry entries that
support this usage, although I agree that everyone should be using
IKEv2 in preference to IKEv1.

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com    Mobile: +1 (978) 394-7754

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of 
> Tero Kivinen
> Sent: Wednesday, April 06, 2011 7:44 AM
> To: Vinod Sasi
> Cc: ipsec@ietf.org; 'Scott Fluhrer (sfluhrer)'
> Subject: Re: [IPsec] Queries relating to ESP/AH GCM & GMAC
> 
> Vinod Sasi writes:
> > Many thanks for your reply; this is helping me to a great extent.
> 
> In the RFC6071 we do note that those combined mode ciphers are not
> feature of the old IPsec-v2 set (i.e IKEv1). I would recommend not to
> implement them using IKEv1, as there might be quite a lot of
> interoperability issues, especially as the documentation how to use
> them in IKEv1 is non-existing and different implementations might use
> different interpretation how some document text should be applied in
> this context.
> 
> The text in the RFC6071 (IPsec Roadmap) says:
> 
> --
> 5.4.  Combined Mode Algorithms
> 
>IKEv1 and ESP-v2 use separate algorithms to provide encryption and
>integrity protection, and IKEv1 can negotiate different combinations
>of algorithms for different SAs.  In ESP-v3, a new class of
>algorithms was introduced, in which a single algorithm can provide
>both encryption and integrity protection.  [RFC5996] describes how
>IKEv2 can negotiate combined mode algorithms to be used in ESP-v3
>SAs.  [RFC5282] adds that capability to IKEv2, enabling IKEv2 to
>negotiate and use combined mode algorithms for its own traffic.  When
>properly designed, these algorithms can provide increased efficiency
>in both implementation and execution.
> 
>Although ESP-v2 did not originally include combined mode algorithms,
>some IKEv1 implementations have added the capability to negotiate
>combined mode algorithms for use in IPsec SAs; these implementations
>do not include the capability to use combined mode algorithms to
>protect IKE SAs.  IANA numbers for combined mode algorithms have been
>added to the IKEv1 registry.
> ...
> 5.4.2.  RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec
> Encapsulating Security Payload (ESP) (S, June 2005)
> ...
>Requirement levels for AES-GCM:
> 
>  IKEv1 - N/A
>  IKEv2 - optional
>  ESP-v2 - N/A
>  ESP-v3 - optional [RFC4835]
> 
>NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but
>combined mode algorithms are not a feature of IPsec-v2.  Although
>some IKEv1/IPsec-v2 implementations include this capability (see
>Section 5.4), it is not part of the protocol.
> --
> 
> So unless this feature is really needed for some internal use case, I
> would recommend using IKEv2 instead.
> 
> Do not expect this feature to be interoperable with other IPsec
> implementations unless you specifically test it.
> 
> > 

[IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-09

[david.black]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq .

Summary:
This draft is ready for publication as an Informational RFC.

The -09 version of this draft has satisfactorily addressed all of the comments 
in the Gen-ART review of the -08 version.  Many thanks to the authors.

Thanks,
--David


> -Original Message-
> From: Black, David
> Sent: Sunday, July 11, 2010 10:57 PM
> To: 'gen-...@ietf.org'; Frankel, Sheila E.; 'suresh.krish...@ericsson.com'
> Cc: ipsec@ietf.org; Paul Hoffman; Yaron Sheffer; Sean Turner; Black, David
> Subject: Gen-ART review of draft-ietf-ipsecme-roadmap-08
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq .
> 
> Please resolve these comments along with any other comments you may receive.
> 
> Summary:
> This draft is on the right track, but has open issues, described in the 
> review.
> 
> This is a very useful summary of all of the RFCs (and some in-progress 
> Internet-Drafts) that specify
> or are related to IPsec.  It will be very useful to those new to IPsec, as it 
> describes the
> organization of the RFCs and relationships among them.
> 
> I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the applicability 
> of combined mode
> algorithms to IPsec-v2.  All of the other comments in this review are minor.
> 
> Section 2.2 lists the RFC # range for IPsec-v1.  Please also list the RFC # 
> ranges for IPsec-v2 and
> IPsec-v3.
> 
> ** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode 
> algorithms are "not a
> feature of IPsec-v2" and hence lists them as N/A.  That's not correct.  The 
> correct situation is:
> - Combined mode algorithms for ESP can be negotiated as encryption
>   algorithms (the integrity protection algorithm would typically
>   be omitted proposals that do this).
> - Combined mode algorithms cannot be used with IKEv1, as they're
>   incompatible with its design (see the Introduction section of
>   RFC 5282 for a more detailed explanation).
> Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM 
> should be "optional" for
> ESPv2 (and the NOTE should be revised accordingly).
> 
> Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116.
> 
> Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3.  If that 
> is correct, it should be
> stated.
> 
> Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating 
> that should comment that
> this was not widely adopted, and NAT traversal is the commonly used mechanism 
> to deal with NATs.
> 
> In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel".  If you want to 
> cite the RFCs involved, IP
> over FC is RFC 4338 and FC over IP is RFC 3821.
> 
> idnits 2.12.04 found some minor nits:
> 
>   ** There are 4 instances of too long lines in the document, the longest one
>  being 3 characters in excess of 72.
> 
> Thanks,
> --David
> 
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> david.bl...@emc.com    Mobile: +1 (978) 394-7754
> 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Roadmap doc updated in response to Gen-ART Review

[david.black]

Sheila and Suresh,

These changes look good.  The only thing I would have added is a
sentence in Section 8.8.1 to say that RFC 2709's security model has not
been widely adopted, and the more common approach is NAT traversal.
Whether to add this is a matter of editorial taste, as NAT traversal is
covered earlier in the draft (Sections 3.2.1 and 4.1.2.1), so the -09
version of this draft is fine with me

Many thanks for all the time and effort that you've put into this draft.

Thanks,
--David

> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Frankel, Sheila E.
> Sent: Tuesday, August 10, 2010 1:31 PM
> To: Black, David; paul.hoff...@vpnc.org; gen-...@ietf.org;
suresh.krish...@ericsson.com
> Cc: ipsec@ietf.org; turn...@ieca.com; yaron.i...@gmail.com
> Subject: [IPsec] Roadmap doc updated in response to Gen-ART Review
> 
> An updated IPsec/IKE roadmap (version 09) was submitted in response to
the Gen-ART review.
> Here are the changes that were made in response to that review:
> 
> > I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the
applicability
> > of combined mode algorithms to IPsec-v2.  All of the other comments
in this
> > review are minor.
> 
> See below.
> 
> > Section 2.2 lists the RFC # range for IPsec-v1.  Please also list
the RFC
> > # ranges for IPsec-v2 and IPsec-v3.
> 
> The v1 RFCs are mentioned here for completeness, since they are not
included
> elsewhere. For v2 and v3, added the phrase "see Section 3.1.x for the
RFC
> descriptions."
> 
> > ** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that
combined mode
> > algorithms are "not a feature of IPsec-v2" and hence lists them as
N/A.
> > That's not correct.  The correct situation is:
> > - Combined mode algorithms for ESP can be negotiated as encryption
> > algorithms (the integrity protection algorithm would
typically
> > be omitted proposals that do this).
> > - Combined mode algorithms cannot be used with IKEv1, as they're
> > incompatible with its design (see the Introduction section
of
> > RFC 5282 for a more detailed explanation).
> > Hence the N/A entries for IKEv1 are correct, but both AES-CCM and
AES-GCM
> > should be "optional" for ESPv2 (and the NOTE should be revised
accordingly).
> 
> The roadmap already includes the following statement in Section 5.4:
>Although ESP-v2 did not originally include combined mode
algorithms,
>some IKEv1 implementations have added the capability to negotiate
>combined mode algorithms for use in IPsec SAs; these
implementations
>do not include the capability to use combined mode algorithms to
>protect IKE SAs.
> 
> Added the following to the NOTEs for the combined mode algorithms:
>   Although some IKEv1/IPsec-v2 implementations include this capability
>   (see Section 5.4), it is not part of the protocol.
> 
> > Section 5.4.3 - RFC 5282 is based on a combined mode framework in
RFC 5116.
> 
> RFC 5116 described the underlying framework, but does not mention IKE
or IPsec.
> Just as this doc does not include the RFCs that define the SHA-1
algorithm or
> the HMAC algorithm, it does not include this framework RFC.
> 
> > Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3.
If that
> > is correct, it should be stated.
> 
> Added "This document applies only to IKEv1 and IPsec-v2; it does not
apply to IKEv2 and IPsec-v3."
> 
> > Section 8.8.1 also appears to be IPsec-v2 only, and in addition to
stating
> > that should comment that this was not widely adopted, and NAT
traversal
> > is the commonly used mechanism to deal with NATs.
> 
> Added "Although the model presented here uses terminology from IKEv1,
it can be deployed within
> IKEv1, IKEv2, IPsec-v2 and IPsec-v3.
> 
> > In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel".  If you
want
> > to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is
RFC 3821.
> 
> Deleted "/SCSI" In general, the roadmap only cites IKE/IPsec-related
RFCs, but
> not the RFCs that define the non-IKE/IPsec underlying protocols.
Although
> RFC 3821 mentions the use of IKE/IPsec for Fibre Channel, unlike RFC
4595, it
> does not alter IKE/IPsec in any way.
> 
> > idnits 2.12.04 found some minor nits:
> 
> >   ** There are 4 instances of too long lines in the document, the
longest one
> >  being 3 characters in excess of 72.
> 
> Fixed this.
> 
> Sheila and Suresh
> ___
> 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] Gen-ART review of draft-ietf-ipsecme-roadmap-08

[david.black]

Paul,

> >Section 2.2 lists the RFC # range for IPsec-v1.  Please also list the
RFC # ranges for IPsec-v2 and
> IPsec-v3.
> 
> Disagree. The definition of IPsec-v2 and -v3 is complicated, as is
clear from the document. Listing
> RFCs here will send the wrong message.

How about listing the RFC # for just the architecture RFCs (2401 for v2,
4301 for v3)?  It seems odd/inconsistent to indicate in this section
where in the RFC sequence one can find only the truly obsolete IPsec-v1.

> >** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined
mode algorithms are "not a
> > feature of IPsec-v2" and hence lists them as N/A.  That's not
correct.  The correct situation is:
> >- Combined mode algorithms for ESP can be negotiated as encryption
> > algorithms (the integrity protection algorithm would typically
> > be omitted proposals that do this).
> >- Combined mode algorithms cannot be used with IKEv1, as they're
> > incompatible with its design (see the Introduction section of
> > RFC 5282 for a more detailed explanation).
> >Hence the N/A entries for IKEv1 are correct, but both AES-CCM and
AES-GCM should be "optional" for
> >ESPv2 (and the NOTE should be revised accordingly).
> 
> I am having a hard time following your logic here. Where in "IPsec-v2"
do you see combined modes
> as being defined? I agree that they can be negotiated for ESP; why
does that make them a feature
> for all of IPsec-v2?

The current "not a feature of IPsec-v2" language will be (mis)read as
"cannot be used with IPsec-v2."  Since we agree that the latter
implication is incorrect, the language should be edited to avoid
creating that incorrect implication.

[... snip ...]

> >Section 8.8.1 also appears to be IPsec-v2 only, and in addition to
stating that should comment that
> this was not widely adopted, and NAT traversal is the commonly used
mechanism to deal with NATs.
> 
> RFC 2709 was only a model, not a protocol. The model and protocol are
both part of IPsec-v3, but RFC
> 2709 was not "part of" IPsec-v2 in that it was suggestions for
deployment.

I suggest adding some form of the above two sentences to 8.8.1 for
clarity.

Thanks,
--David

> -Original Message-
> From: Paul Hoffman [mailto:paul.hoff...@vpnc.org]
> Sent: Friday, July 16, 2010 3:19 PM
> To: Black, David; gen-...@ietf.org; sheila.fran...@nist.gov;
suresh.krish...@ericsson.com
> Cc: ipsec@ietf.org; turn...@ieca.com; Black, David;
yar...@checkpoint.com
> Subject: Re: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08
> 
> At 10:56 PM -0400 7/11/10,  wrote:
> >Section 2.2 lists the RFC # range for IPsec-v1.  Please also list the
RFC # ranges for IPsec-v2 and
> IPsec-v3.
> 
> Disagree. The definition of IPsec-v2 and -v3 is complicated, as is
clear from the document. Listing
> RFCs here will send the wrong message.
> 
> >** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined
mode algorithms are "not a
> feature of IPsec-v2" and hence lists them as N/A.  That's not correct.
The correct situation is:
> >- Combined mode algorithms for ESP can be negotiated as encryption
> > algorithms (the integrity protection algorithm would typically
> > be omitted proposals that do this).
> >- Combined mode algorithms cannot be used with IKEv1, as they're
> > incompatible with its design (see the Introduction section of
> > RFC 5282 for a more detailed explanation).
> >Hence the N/A entries for IKEv1 are correct, but both AES-CCM and
AES-GCM should be "optional" for
> ESPv2 (and the NOTE should be revised accordingly).
> 
> I am having a hard time following your logic here. Where in "IPsec-v2"
do you see combined modes as
> being defined? I agree that they can be negotiated for ESP; why does
that make them a feature for all
> of IPsec-v2?
> 
> >Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC
5116.
> 
> I think you meant this for 5.4.4. It is a reasonable addition.
> 
> >Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3.
If that is correct, it should be
> stated.
> 
> Good catch, it should be stated.
> 
> >Section 8.8.1 also appears to be IPsec-v2 only, and in addition to
stating that should comment that
> this was not widely adopted, and NAT traversal is the commonly used
mechanism to deal with NATs.
> 
> RFC 2709 was only a model, not a protocol. The model and protocol are
both part of IPsec-v3, but RFC
> 2709 was not "part of" IPsec-v2 in that it was suggestions for
deployment.
> 
> >In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel".
> 
> Agree.
> 
> >If you want to cite the RFCs involved, IP over FC is RFC 4338 and FC
over IP is RFC 3821.
> 
> I don't those help here.
> 
> >idnits 2.12.04 found some minor nits:
> >
> >  ** There are 4 instances of too long lines in the document, the
longest one
> > being 3 characters in excess of 72.
> 
> These are non-visible gremlins; the RFC Production Center can squash
them easily.
> 
> --Paul Hoffman, Director
> --VPN Consortium

__

[IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-08

[david.black]

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq . 

Please resolve these comments along with any other comments you may receive.

Summary:
This draft is on the right track, but has open issues, described in the review.

This is a very useful summary of all of the RFCs (and some in-progress 
Internet-Drafts) that specify or are related to IPsec.  It will be very useful 
to those new to IPsec, as it describes the organization of the RFCs and 
relationships among them. 

I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the applicability 
of combined mode algorithms to IPsec-v2.  All of the other comments in this 
review are minor.

Section 2.2 lists the RFC # range for IPsec-v1.  Please also list the RFC # 
ranges for IPsec-v2 and IPsec-v3.

** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode 
algorithms are "not a feature of IPsec-v2" and hence lists them as N/A.  That's 
not correct.  The correct situation is:
- Combined mode algorithms for ESP can be negotiated as encryption
algorithms (the integrity protection algorithm would typically
be omitted proposals that do this).
- Combined mode algorithms cannot be used with IKEv1, as they're
incompatible with its design (see the Introduction section of
RFC 5282 for a more detailed explanation).
Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM 
should be "optional" for ESPv2 (and the NOTE should be revised accordingly).

Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116.

Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3.  If that is 
correct, it should be stated.

Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating that 
should comment that this was not widely adopted, and NAT traversal is the 
commonly used mechanism to deal with NATs.

In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel".  If you want to 
cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC 3821.

idnits 2.12.04 found some minor nits:

  ** There are 4 instances of too long lines in the document, the longest one
 being 3 characters in excess of 72.

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com    Mobile: +1 (978) 394-7754


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec