Paul Hoffman / VPNC | 1 Jun 06:07 2004

Re: draft-ietf-ipsec-ikev2-14.txt

At 11:47 PM -0700 5/29/04, Charlie Kaufman wrote:
>I just forwarded it to internet-drafts, copying Paul Hoffman in hopes he
>will post it on his web page faster than the I-D editor will get to it.

Done. It is available at 
<http://www.vpnc.org/ietf-ipsec/TEMP-draft-ietf-ipsec-ikev2-14.txt>. 
This temporary file will be removed when the draft is officially 
posted to the Internet Drafts directory.

--Paul Hoffman, Director
--VPN Consortium
Tero Kivinen | 1 Jun 15:48 2004
Picon
Picon

Comments to the draft-ietf-ipsec-rfc2401bis-02.txt

> 4.4 Major IPsec Databases
> ...
>     Multiple Separate IPsec Contexts
> ...
>        For example, a security gateway that provides VPN service to
>        multiple customers will be able to associate each customer~Os
								   ^^^^
I assume it should be ' there instead of that "~<ctrl-h>O".

>        traffic with the correct VPN.
> ...
> 4.4.1.1  Selectors
> ...
>       * If the Next Layer Protocol uses two ports (e.g., TCP, UDP, SCTP,
>         these selectors is a list of ranges of values.  Note that the
>         Local and Remote ports may not be available in the case of
>         receipt of a fragmented packet, thus a value of OPAQUE also MUST
>         be supported.  Note: In a non-initial fragment, port values will
>         not be available. If a port selector specifies a value other than
>         ANY or OPAQUE, it cannot match packets that are non-initial
>         fragments.  If the SA requires a port value other than ANY or
>         OPAQUE, an arriving fragment without ports MUST be discarded.

This thing depends on the fragmentation handling. Support of OPAQUE
should not be mandatory, as it is only needed to support to one of the
fragmentation handling proposals, and that one is most likely going to
be MAY or SHOULD, not MUST.

I propose removing everything after ", thus a value of OPAQUE ..." and
replace it with reference to section 7.
(Continue reading)

Barbara Fraser | 1 Jun 18:32 2004
Picon

Confirmation that IKEv2 is ready

Hi Russ,

Just an FYI that we believe Charlie's latest document addresses all the 
outstanding issues from IETF last call and is ready for advancement.

thanks,
Barb and Ted
vamsi | 1 Jun 23:42 2004

IKEv2 and EAP-SIM

Hi All,

In section 2.16 of IKEv2 draft states that, when EAP is used, initiator MUST
     authenticate the server using public key signatures. Some EAP methods 
provide
     mutual authentication. Should n't  this requirement be relaxed to 
support EAP methods
     such as EAP-SIM?  I would prefer the statement such as, if EAP method 
does not
     support mutual authentication, then the initiator MUST authenticate 
the responder
     using public key signatures.

Thanks
Vamsi
CTO Office
Intoto Inc.
www.intoto.com
Yoav Nir | 2 Jun 09:04 2004
Picon

Re: IKEv2 and EAP-SIM

See this draft:

http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-eap-auth 
-01.txt   "Extension for EAP Authentication in IKEv2"

On Jun 2, 2004, at 12:42 AM, vamsi wrote:

> Hi All,
>
> In section 2.16 of IKEv2 draft states that, when EAP is used,  
> initiator MUST
>     authenticate the server using public key signatures. Some EAP  
> methods provide
>     mutual authentication. Should n't  this requirement be relaxed to  
> support EAP methods
>     such as EAP-SIM?  I would prefer the statement such as, if EAP  
> method does not
>     support mutual authentication, then the initiator MUST  
> authenticate the responder
>     using public key signatures.
>
>
>
> Thanks
> Vamsi
> CTO Office
> Intoto Inc.
> www.intoto.com
>
>
(Continue reading)

Hazem Hamed | 2 Jun 17:26 2004
Picon

IPSec Outbound Packet Processing Questions

Hi Everybody,

I am a PhD student in DePaul University, Chicago doing research in IPSec. I need clarification about the operation of SPD lookup for outbound packets.

First question, it's not clear how an SA bundle is formed, and if all SAs in the bundle get the same SPI. Is it constructed by matching an outbound packet against multiple SPD rules each pointing to one transform, or matching the packet against one rule that points to multipe transforms?

Second question is about outbound packet matching. Can a packet match multiple SPD rules? If yes, how are these rules applied to the packet in such a case?
 
Any cooperation is highly appreciated.

-Hazem
_______________________________________________
Ipsec mailing list
Ipsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Uri Blumenthal | 2 Jun 18:33 2004
Picon

Re: IKEv2 and EAP-SIM

On 6/1/2004 17:42, vamsi wrote:
> Hi All,
> 
> In section 2.16 of IKEv2 draft states that, when EAP is used, initiator MUST
> authenticate the server using public key signatures. Some EAP methods 
> provide mutual authentication. Should not  this requirement be relaxed to 
> support EAP methods such as EAP-SIM? 

It is an open question whether EAP-SIM offers a reliable mutual authentication.
Thus I'd be against relaxing this requirement for a method such as EAP-SIM.

> I would prefer the statement such as, if EAP method does not
> support mutual authentication, then the initiator MUST authenticate 
> the responder using public key signatures.

In general, I'm ambivalent on this. But since not EAP methods offer equal
strength, perhaps it's best to leave as is...
Internet-Drafts | 2 Jun 22:12 2004
Picon

I-D ACTION:draft-ietf-ipsec-ikev2-14.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.

	Title		: Internet Key Exchange (IKEv2) Protocol
	Author(s)	: C. Kaufman
	Filename	: draft-ietf-ipsec-ikev2-14.txt
	Pages		: 106
	Date		: 2004-6-2
	
This document describes version 2 of the Internet Key Exchange (IKE)
protocol.  IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security
associations.
This version of the IKE specification combines the contents of what
were previously separate documents, including ISAKMP (RFC 2408), IKE
(RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy
authentication, and remote address acquisition.
Version 2 of IKE does not interoperate with version 1, but it has
enough of the header format in common that both versions can
unambiguously run over the same UDP port.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-14.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipsec-ikev2-14.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipsec-ikev2-14.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 134 bytes
Attachment (draft-ietf-ipsec-ikev2-14.txt): message/external-body, 68 bytes
_______________________________________________
Ipsec mailing list
Ipsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Theodore Ts'o | 2 Jun 20:49 2004
Picon
Picon

Results of the Straw Poll re: Fragmentation handling


The results of the straw poll indicated that out of 16 responses,
roughly twice as many contributors (11) preferred that Methods #2 and #3
be a MAY implement, over thouse who preferred that at least one of
Methods #2 and #3 be a SHOULD or a MUST (5).

There was also a somewhat surprising number (albeit a minority)
who registered a strong dislike of Method #2 --- four or five
respondents indicated that they thought Method #2 should be a MUST NOT.

Hence, it seems that we have a rough consensus within the working group
that both Method #2 and #3 should both be MAY.  To accomodate those who
dislike Method #2, I would propose that if we can get someone from that
camp to write a paragraph detailing their objections to mixing
non-initial fragments when initial fragments are not mixed, it would
seem to me reasonable to record the minority dissent in the architecture
specification.

						- Ted

Yoav Nir
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Tero Kivnen
	1.  SHOULD/MUST
	2.  MAY
	3.  SHOULD

Scott G. Kelly
	1.  SHOULD/MUST (for 3 only)
	2.  MUST NOT
	3.  SHOULD

Michael Roe
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Yougui Cheng
	1.  MAY / MAY
	2.  SHOULD NOT
	3.  MAY

Mark Duffy
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Niklas Hallqvist
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Srini
	1.  SHOULD / MUST
	2.  MAY
	3.  SHOULD

Satoshi Inoue
	1.  MAY /  MAY
	2.  MAY
	3.  MAY

Valery Smyslov
	1.  SHOULD / MUST
	2.  MAY
	3.  SHOULD

Paul Hoffman
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Bora Akyol
	1.  MAY  / MAY
	2.  MAY
	3.  MAY

Joe Tardo
	1.  SHOULD / MUST (3 should be MUST)
	2.  MAY
	3.  SHOULD

Markku Savela
	1.  MAY / MAY
	2.  MUST NOT
	3.  MAY

Mika Joutsenvirta
	1.  MAY / MAY
	2.  MAY
	3.  MAY

Joe Touch
	1.  MAY / MAY (2 MUST NOT)
	2.  MUST NOT
	3.  MAY
Scott G. Kelly | 3 Jun 18:51 2004

Re: Results of the Straw Poll re: Fragmentation handling

Hi Ted,

I'm a little surprised at your assessment of my position on question
#2, so I think I must have been unclear.  Here's your summary:

> Scott G. Kelly 
 > 1.  SHOULD/MUST (for 3 only)
 > 2.  MUST NOT
 > 3.  SHOULD

Here's what I said for #2:
> NONE of the above - why even mention this? I doubt there are many
> 100% compliant implementations for the first round of ipsec, and find
> it highly unlikely that this will change. Implementations that don't
> care about fragment security probably don't care about port/protocol
> differentiation. The two seem incompatible and unlikely. I can't
> believe we've wasted so much time/energy on this.

I'm sorry that this was unclear. What I meant to say was, why even 
mention this in the draft at all - why make it an option? I guess my 
point was that if folks want to implement special handling for special 
cases, history has demonstrated that they will do so whether they have 
special dispensation or not. It may not make sense to complicate the 
spec for (what I perceive to be) a very small minority of implementations.

That's not a clear selection of one of the terms you asked for, but it's 
definitely not a MUST NOT. I guess I should have used the RFC2119 
language, in which case I might say "SHOULD NOT", meaning someone that 
really knows what they are doing might have justification, but this 
should not be casually undertaken. I think the current draft rev gives 
cautions for ipv6, but we might want similar cautions for ipv4.

The primary assumption underlying a fragment-only SA is that the other 
end can be trusted to only put allowable data into the tunnel. 
Sometimes this assumption is justified, but this is certainly not always 
the case. Hence, this assumption must be evaluated prior to implementing 
a fragment-only tunnel.

As an aside, I wonder if anyone requiring such a thing in practice 
wouldn't be better off to simply "tunnel-all" over a single SA pair.

--Scott

Theodore Ts'o wrote:

> The results of the straw poll indicated that out of 16 responses, 
> roughly twice as many contributors (11) preferred that Methods #2 and
> #3 be a MAY implement, over thouse who preferred that at least one of
>  Methods #2 and #3 be a SHOULD or a MUST (5).
> 
> There was also a somewhat surprising number (albeit a minority) who
> registered a strong dislike of Method #2 --- four or five respondents
> indicated that they thought Method #2 should be a MUST NOT.
> 
> Hence, it seems that we have a rough consensus within the working
> group that both Method #2 and #3 should both be MAY.  To accomodate
> those who dislike Method #2, I would propose that if we can get
> someone from that camp to write a paragraph detailing their
> objections to mixing non-initial fragments when initial fragments are
> not mixed, it would seem to me reasonable to record the minority
> dissent in the architecture specification.
> 
> - Ted
> 
> 
> Yoav Nir 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Tero Kivnen 1.  SHOULD/MUST 2.  MAY 3.  SHOULD
> 
> Scott G. Kelly 1.  SHOULD/MUST (for 3 only) 2.  MUST NOT 3.  SHOULD
> 
> Michael Roe 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Yougui Cheng 1.  MAY / MAY 2.  SHOULD NOT 3.  MAY
> 
> Mark Duffy 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Niklas Hallqvist 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Srini 1.  SHOULD / MUST 2.  MAY 3.  SHOULD
> 
> Satoshi Inoue 1.  MAY /  MAY 2.  MAY 3.  MAY
> 
> Valery Smyslov 1.  SHOULD / MUST 2.  MAY 3.  SHOULD
> 
> Paul Hoffman 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Bora Akyol 1.  MAY  / MAY 2.  MAY 3.  MAY
> 
> Joe Tardo 1.  SHOULD / MUST (3 should be MUST) 2.  MAY 3.  SHOULD
> 
> Markku Savela 1.  MAY / MAY 2.  MUST NOT 3.  MAY
> 
> 
> Mika Joutsenvirta 1.  MAY / MAY 2.  MAY 3.  MAY
> 
> Joe Touch 1.  MAY / MAY (2 MUST NOT) 2.  MUST NOT 3.  MAY
> 
> 
> 
> _______________________________________________ Ipsec mailing list 
> Ipsec <at> ietf.org https://www1.ietf.org/mailman/listinfo/ipsec

Gmane