Re: [IPsec] WG Adoption call for draft-mglt-ipsecme-ikev2-diet-esp-extension

[Tommy Pauly]

I also support adopting this document, and am also happy to review it. 

Thanks,
Tommy

> On Nov 27, 2023, at 10:35 AM, Tero Kivinen  wrote:
> 
> This is two week adoption call for
> draft-mglt-ipsecme-ikev2-diet-esp-extension. If you support adopting
> this document as a working group document for IPsecME to work on, and
> then at some point publish this as an RFC, send comments to this list.
> 
> This adoption call ends 2023-12-13.
> 
> Note, that I do want to see people saying that they think this
> document is worth of working on, and that they plan to review and
> comment on it. If I only get one or two people (including authors :-)
> to say they support this work, then there is no point of work on this
> in WG.
> --
> 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] WG Adoption call for draft-mglt-ipsecme-diet-esp

[Tommy Pauly]

I support adoption of this document, and am happy to review it through the 
working group process. 

Thanks,
Tommy

> On Nov 27, 2023, at 10:34 AM, Tero Kivinen  wrote:
> 
> This is two week adoption call for draft-mglt-ipsecme-diet-esp. If you
> support adopting this document as a working group document for IPsecME
> to work on, and then at some point publish this as an RFC, send
> comments to this list.
> 
> This adoption call ends 2023-12-13.
> 
> Note, that I do want to see people saying that they think this
> document is worth of working on, and that they plan to review and
> comment on it. If I only get one or two people (including authors :-)
> to say they support this work, then there is no point of work on this
> in WG.
> --
> 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] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 for your review)

[Tommy Pauly]

As with DNR, I definitely think we should be using the wire format here (for 
communicating on the wire). The IKE option here would carry the binary format 
for the parameters, and it doesn’t require the IKE implementation to do any 
parsing, etc on that.

Since it looks like there’s good consensus on the DNR side in the ADD WG, I 
think the most important thing to do is ensure the same format is used for IKE 
as is used elsewhere. For DDR, DNR, and this IKE extension, they should all use 
the same format, whether the information is in a DNS packet, a DHCP packet, or 
an IKE packet.

Thanks,
Tommy

> On Oct 4, 2023, at 5:28 AM, Paul Wouters  wrote:
> 
> As I said over the other side, I prefer presentation format. Here that is 
> even more true than over at the dhcp server because ike daemons (server AND 
> client) tend to not implement dns wire format.
> 
> Presentation format would be to reject this change.
> 
> But whichever is picked, if I am in the rough, do make it the same format for 
> both drafts.
> 
> Paul
> 
> Sent using a virtual keyboard on a phone
> 
>> On Oct 4, 2023, at 06:33, mohamed.boucad...@orange.com wrote:
>> 
>> Hi all, =
>> 
>> 
>> This document is already in AUTH48-DONE but still not published yet because=
>> of a normative dependency (see more about the cluster at  https://www.rfc-=
>> editor.org/auth48/C461).
>> 
>> A late issue was raised about the encoding of the service parameters (repre=
>> sentation format vs wire format). A summary can be found at: https://mailar=
>> chive.ietf.org/arch/msg/add/qU_TaosKNhojs3h3ojUb0B_bpXg/.
>> 
>> In order to be consistent with the consensus in ADD, I suggest we update RF=
>> C-to-be 9464 as follows: =
>> 
>> 
>> OLD:
>>  Service Parameters (SvcParams) (variable) -  Specifies a set of
>> service parameters that are encoded following the rules in
>> Section 2.1 of [RFC9460].  =
>> 
>> 
>> NEW:
>>  Service Parameters (SvcParams) (variable) -  Specifies a set of
>> service parameters that are encoded following the same rules
>> for encoding SvcParams using the wire format specified
>> in Section 2.2 of [RFC9460]. =
>> 
>> 
>> The text may seem verbose but the intent is to avoid ambiguity and be expli=
>> cit about which part of Section 2.2 of [RFC9460].
>> 
>> Unless we hear an objection by the end of the week, we will request the RFC=
>> Editor to make this change. =
>> 
>> 
>> Cheers,
>> Med
>> ___=
>> _
>> Ce message et ses pieces jointes peuvent contenir des informations confiden=
>> tielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
>> ectroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou =
>> falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged inf=
>> ormation that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and dele=
>> te this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been =
>> modified, changed or falsified.
>> Thank you.
>> 
> 
> ___
> 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] WGLC of draft-ietf-ipsecme-add-ike

[Tommy Pauly]

> On Aug 11, 2022, at 2:13 AM, Valery Smyslov  wrote:
> 
> Hi Tommy,
>  
> thank you for the review and for the proposed changes.
> I reviewed them and they look good to me.
> I still disagree with one requested change, see below.
>  
> From: IPsec mailto:ipsec-boun...@ietf.org>> On 
> Behalf Of Tommy Pauly
> Sent: Wednesday, August 10, 2022 7:33 PM
> To: Tero Kivinen mailto:kivi...@iki.fi>>; ipsec@ietf.org 
> <mailto:ipsec@ietf.org>
> Subject: Re: [IPsec] WGLC of draft-ietf-ipsecme-add-ike
>  
> I’ve done a review pass of this document. In general, I think it is 
> technically good.
>  
> I did find several places where I think additional clarity or editorial 
> improvements could be made. To address these, I’ve proposed the following 
> pull request: https://github.com/boucadair/draft-ietf-ipsecme-add-ike/pull/5 
> <https://github.com/boucadair/draft-ietf-ipsecme-add-ike/pull/5>
>  
> Some of the revenant items I am trying to address are:
> - Make it more clear early on that the attributes are generically 
> communicating encrypted DNS resolvers, and don’t define specific details for 
> DoH/DoT/DoQ (that comes from the SVCB-DNS draft)
> - Be more explicit about how ENCDNS_IP* are two specific types, ENCDNS_IP4 
> and ENCDNS_IP6
> - Introduce and explain ENCDNS_DIGEST_INFO earlier on. Currently, it is 
> defined with no explanation until a later section.
> - Clarify the behavior of the initiator for including ENCDNS_IP* attributes. 
> Specifically, I believe this is intended to be: either include exactly one 
> empty ENCDNS_IP* attribute of a given type to request “any” encrypted DNS 
> resolver on that address family; OR, include one or more of that type with 
> hints about the addresses and APNs being requested. This was implied by the 
> text previously, but not clear.
>  
> I think there is some inconsistency here and the proposed text doesn't 
> address it. 
> The text requires that the initiator MUST NOT send more than one empty 
> attribute of a given type,
> but what about sending multiple non-empty attributes with the same content?
>  
> I believe we should say that the initiator MAY send several ENCDNS_IP4 and 
> ENCDNS_IP6 attributes,
> but all of them MUST be distinct (either empty or specifying different 
> resolvers). 
> The responder MUST ignore repeated attributes if any.

Sure, being even more clear to explain that each attribute must be distinct is 
good! Please amend the text to that effect, as you see fit.

Best,
Tommy
>  
>   Regards,
>   Valery.
>  
> If these items are addressed, I’m happy to see this progress.
>  
> Thanks,
> Tommy
> 
> 
>> On Aug 9, 2022, at 1:47 PM, Tero Kivinen > <mailto:kivi...@iki.fi>> wrote:
>>  
>> This is the start of 2 week WGLC on the document, ending 2022-08-17.
>> Please submit your comments to the list, also send a note if you have
>> reviewed the document, so we can see how many people are interested in
>> getting this out.
>> -- 
>> kivi...@iki.fi <mailto:kivi...@iki.fi>
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org <mailto:IPsec@ietf.org>
>> https://www.ietf.org/mailman/listinfo/ipsec 
>> <https://www.ietf.org/mailman/listinfo/ipsec>
>  

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

Re: [IPsec] WGLC of draft-ietf-ipsecme-add-ike

[Tommy Pauly]

I’ve done a review pass of this document. In general, I think it is technically 
good.

I did find several places where I think additional clarity or editorial 
improvements could be made. To address these, I’ve proposed the following pull 
request: https://github.com/boucadair/draft-ietf-ipsecme-add-ike/pull/5

Some of the revenant items I am trying to address are:
- Make it more clear early on that the attributes are generically communicating 
encrypted DNS resolvers, and don’t define specific details for DoH/DoT/DoQ 
(that comes from the SVCB-DNS draft)
- Be more explicit about how ENCDNS_IP* are two specific types, ENCDNS_IP4 and 
ENCDNS_IP6
- Introduce and explain ENCDNS_DIGEST_INFO earlier on. Currently, it is defined 
with no explanation until a later section.
- Clarify the behavior of the initiator for including ENCDNS_IP* attributes. 
Specifically, I believe this is intended to be: either include exactly one 
empty ENCDNS_IP* attribute of a given type to request “any” encrypted DNS 
resolver on that address family; OR, include one or more of that type with 
hints about the addresses and APNs being requested. This was implied by the 
text previously, but not clear.

If these items are addressed, I’m happy to see this progress.

Thanks,
Tommy

> On Aug 9, 2022, at 1:47 PM, Tero Kivinen  wrote:
> 
> This is the start of 2 week WGLC on the document, ending 2022-08-17.
> Please submit your comments to the list, also send a note if you have
> reviewed the document, so we can see how many people are interested in
> getting this out.
> -- 
> 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] WG Adoption call for draft-btw-add-ipsecme-ike

[Tommy Pauly]

I support adoption of this work. The mechanism of specifying the authentication 
domain name and service parameters is sound, and the right direction.

I do agree with Paul Wouter’s comments, and I think the parts of the document 
that deal with requirements for config requests need work. Ideally, this 
doesn’t need to update split-DNS, but instead just reference the fact that the 
encrypted resolvers MUST always be preferred when present.

The text also needs to be careful about not over-mandating behavior. For 
example, the text currently says the following:

   If the IPsec connection is a split-tunnel configuration and the
   initiator negotiated INTERNAL_DNS_DOMAIN as per [
RFC8598
], the DNS
   client MUST resolve the internal names using ENCDNS_IP* DNS servers.

RFC 8598 has a bit more leeway, explaining that there may be some domains that 
are prohibited by local policy from being claimed by the IKE tunnel. This needs 
to be maintained.

For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that is not
   prohibited by local policy, the client MUST use the provided
   INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only
   resolvers for the listed domains and its subdomains, and it MUST NOT
   attempt to resolve the provided DNS domains using its external DNS
   servers.

Best,
Tommy

> On Nov 8, 2021, at 6:17 AM, Tero Kivinen  wrote:
> 
> This is the start of 2 week WG adoption call for this document, ending
> 2021-11-22. Please send your reply about whether you support adopting
> this document as WG document or not.
> -- 
> 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] rfc8229bis missing advise on error handling in IKE_INIT

[Tommy Pauly]

> On Mar 19, 2021, at 12:36 PM, Paul Wouters  wrote:
> 
> 
> Hi,
> 
> We have implemented TCP but are running in some issues where the RFC and
> the bis draft does not give us clarify.
> 
> If the IKE_INIT over TCP gets back an INVALID_KE, what is supposed to
> happen? Is the responder expected to close the TCP session, since it
> never created a state for this exchange? Is the initiator expected
> to re-use the TCP connection to send a fresh new IKE_INIT request
> with the proper KE ? This case is similar to the COOKIE case, but
> there the initiator is expected to keep state and re-use, except
> one is not supposed to trigger COOKIES on TCP.

My interpretation here, and the way our client works, is that the connection 
may be reused.

From 7296:

 If the
   initiator guesses wrong, the responder will respond with a Notify
   payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
   this case, the initiator MUST retry the IKE_SA_INIT with the
   corrected Diffie-Hellman group.

This implies that the new IKE_SA_INIT is a retry of the same IKE SA. Indeed, at 
least for our client, we don’t reset the SA values.

If that is the interpretation of the retry after INVALID_KE_PAYLOAD, it doesn’t 
violate 8229:

   Multiple IKE SAs MUST NOT share a single TCP connection, unless one
   is a rekey of an existing IKE SA, in which case there will
   temporarily be two IKE SAs on the same TCP connection.

> 
> Note I think this sentence is incorrect:
> 
>   Moreover, a TCP Responder creates state once a SYN packet is received
> 
> libreswan listens on the TCP socket, but for INVALID_KE responses it
> creates a response without creating a state.

This sounds like a good clarification to make. We can say that it may create 
state at that point.
> 
> Similarly, when IKE_AUTH fails with NO_PROPOSAL_CHOSEN or
> AUTHENTICATION_FAILED, who is responsible for closing the TCP socket?
> The initiator or the responder?

8229 says:

   In order to close an IKE session, either the Initiator or Responder
   SHOULD gracefully tear down IKE SAs with DELETE payloads.  Once the
   SA has been deleted, the TCP Originator SHOULD close the TCP
   connection if it does not intend to use the connection for another
   IKE session to the TCP Responder.  If the connection is left idle and
   the TCP Responder needs to clean up resources, the TCP Responder MAY
   close the TCP connection.

This generally means: client goes first when closing TCP, but server should 
close if the client doesn’t in time.

> 
> Perhaps a similar issue happens when an IKE lifetime is reached before
> a rekey or re-auth happened. But in that case I guess the party sending
> the delete can linger briefly for the reply and then close the socket
> if it didn't get closed by the responder to the delete request.

Note also that a new TCP connection can always be used for an IKE SA from an 
old connection; that is allowed, so it’s possible that if the server closes too 
early, the client will reopen with a new connection to send remaining messages.

Thanks,
Tommy
> 
> Paul
> 
> ___
> 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] Clarifications and Implementation Guidelines for using TCP Encapsulation in IKEv2 draft

[Tommy Pauly]

Hi Valery,

Thanks for bringing this up again. Would you be interested in making this an 
RFC8229bis instead? I think it would be most useful for an implementer to fold 
some of these clarifications into the main text itself. How do you feel about 
that?

Best,
Tommy

> On Apr 28, 2020, at 2:54 AM, Valery Smyslov  wrote:
> 
> Hi,
> 
> a one and half year ago at IETF 103 in Bangkok I presented
> draft-smyslov-ipsecme-tcp-guidelines
> "Clarifications and Implementation Guidelines for using TCP Encapsulation in
> IKEv2"
> (https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-tcp-guidelines/).
>> From my recollection of the meeting and from minutes it was a general
> feeling in the room that 
> this document was useful for implementers, since it clarified some subtle
> issues
> that were not covered in RFC 8229. However, at that time no adoption call
> was issued since this work would require to update the IPSECME charter.
> It took over a year to adopt the updated charter and now the WG
> is chartered for this work with this draft as a possible starting point.
> The text in the charter:
> 
>   RFC8229, published in 2017, specifies how to encapsulate 
>   IKEv2 and ESP traffic in TCP. Implementation experience has 
>   revealed that not all situations are covered in RFC8229, and that
> may 
>   lead to interoperability problems or to suboptimal performance. The
> WG 
>   will provide a document to give implementors more guidance about how
> to use 
>   reliable stream transport in IKEv2 and clarify some issues that have
> been 
>   discovered.
> 
> However, since it was so long since the WG last discussed the draft, the
> chairs asked me to 
> send a message to the list to determine whether there is still an interest 
> in the WG to proceed with this work with this draft as a starting point. 
> 
> Regards,
> Valery.
> 
> 
> 
> ___
> 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] Adoption call for draft-hopps-ipsecme-iptfs

[Tommy Pauly]

I've read the document and think this is good problem area to work on, and this 
document is a good starting place to adopt.

Going forward, I would like to see more discussion and review of the use IP 
fragmentation (how often is that really needed, and is it worth the concerns 
stated in https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-17), as 
well as the use of Congestion Control (considerations for how having multiple 
layers of CC works, and if we can make sure that the format of the payload is 
aligned with current work in QUIC, etc).

Thanks,
Tommy

> On Oct 26, 2019, at 8:17 AM, Tero Kivinen  wrote:
> 
> So this is fast (one week) adoption call for the
> draft-hopps-ipsecme-iptfs draft to be accepted to the WG document. We
> did have quite positive feedback in last IETF meeting and the charter
> item is being worked on in parallel to this call.
> 
> If you support adopting this document as WG document and as a starting
> place for the charter item proposed for the WG, then send email
> indicating your support to the ipsec@ietf.org mailing-list. If you
> have any comments or reservations send them to list too.
> 
> This adoption call finishes at 2019-11-04.
> 
> --
> The demand for Traffic Flow Confidentiality has been increasing in the user
> community; however, the current method defined in RFC4303 (i.e., add null
> padding to each ESP payload) is very inefficient in it's use of network
> resources. The working group will develop an alternative TFC solution that
> provides for efficient use of network resources.
> -- 
> 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] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX

[Tommy Pauly]

It does seem to a question open to interpretation by the implementation.

I think you can make a good argument for NO_PROPOSAL_CHOSEN in both cases. If 
your implementation interprets things as always getting a list of valid 
proposal values based on the remote address or ID, then any unknown client 
would match the empty list of proposals.

Thanks,
Tommy

> On Jun 20, 2019, at 7:39 AM, Valery Smyslov  wrote:
> 
> Hi Paul,
> 
> generally the INVALID_SYNTAX must be returned when something
> fatal happened, that cannot be fixed by adjusting configuration etc.,
> only re-installing app after bug-fixing would help.
> In contrast, NO_PROPOSAL_CHOSEN means that after some actions from 
> operator the connection would succeed.
> 
>> Hi,
>> 
>> We are having a discussion about which notify to return in certain
>> cases. The issue comes down to the names of the notifies and their
>> actual dictated use in the RFC that does not always intuitively
>> maps to the name.
>> 
>> NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec
>> proposal list matches due to all proposals having at least one mismatching
>> transform" versus "no matching ike connection for your IKE proposal"
>> where proposal refers to the entire IKE proposal, not the proposals
>> list with transforms.
>> 
>> INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC text
>> uses this as the "if all other errors dont match, use this one" so you
>> can end up returning this even if there is no invalid syntax at all.
>> 
>> So if your IPsec gateway only has static IP based VPNs and an unknown IP
>> connects, some feel NO_PROPOSAL_CHOSEN conveys that, while technically,
>> even though there is no invalid syntax in that proposal, the RFC states
>> we should return INVALID_SYNTAX.
> 
> I'd rather not return anything in this case.
> 
>> Similarly, if during IKE_AUTH you are finding out there is no IPsec
>> configuration that matches the incoming client, there is no "proposal
>> list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural
>> match, should we really return INVALID_SYNTAX despite there being no
>> syntax problem? That is what the RFC says.
> 
> I'd return NO_PROPOSAL_CHOSEN.
> 
> Regards,
> Valery.
> 
>> I guess in the end, we are really missing a "CONNECTION_REJECTED"
>> notify that would cover all the things not covered in the more specific
>> notifies.
>> 
>> What do other implementations do? Should we clarify this anywhere?
>> 
>> libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now
>> slated to be more strict to the RFC and use INVALID_SYNTAX. (and
>> clearly, I'm not happy about it but it seems the RFC dictates this)
>> 
>> Paul
>> 
>> ___
>> 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] New Version Notification for draft-pwouters-ikev1-ipsec-graveyard-00.txt

[Tommy Pauly]

Thanks for writing this up! Glad to get rid of IKEv1 =)

I do have a question regarding whether the deprecations for the IKEv2 registry 
are appropriate for this document. RFC 8247 contains the recommendations for 
the which algorithms and DH groups are going away (SHOULD NOT, MUST NOT, etc), 
and it seems like an update to that document or similar would be more 
appropriate to discuss marking deprecation.

Best,
Tommy

> On Mar 11, 2019, at 11:39 AM, Paul Wouters  wrote:
> 
> 
> As we discussed on the list and in Bangkok, we were going to submit a
> document to deprecrate IKEv1 and various old skool algorithms using
> a [DEPRECATED] column in the IANA registry.
> 
> I wrote a first draft to do this...
> 
> Paul
> 
> -- Forwarded message -
> From: 
> Date: Mon, Mar 11, 2019 at 2:35 PM
> Subject: New Version Notification for 
> draft-pwouters-ikev1-ipsec-graveyard-00.txt
> To: Paul Wouters 
> 
> 
> 
> A new version of I-D, draft-pwouters-ikev1-ipsec-graveyard-00.txt
> has been successfully submitted by Paul Wouters and posted to the
> IETF repository.
> 
> Name:   draft-pwouters-ikev1-ipsec-graveyard
> Revision:   00
> Title:  Deprecation of IKEv1 and obsoleted algorithms
> Document date:  2019-03-11
> Group:  Individual Submission
> Pages:  6
> URL:
> https://www.ietf.org/internet-drafts/draft-pwouters-ikev1-ipsec-graveyard-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-pwouters-ikev1-ipsec-graveyard/
> Htmlized:   
> https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-pwouters-ikev1-ipsec-graveyard
> 
> 
> Abstract:
>This document deprecates Internet Key Exchange version 1 (IKEv1) and
>additionally deprecates a number of algorithms that are obsolete.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> ___
> 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] Rename IKE_AUX?

[Tommy Pauly]

I agree that IKE_AUX can be easily confused with IKE_AUTH. Similarly, IKE_INT 
looks a lot like the INIT from IKE_SA_INIT.

I don't necessarily love IKE_PRE_AUTH, but it still seems preferable to the 
other options. You could also spell out "intermediate" to have 
IKE_INTERMEDIATE. This is still shorter than other existing exchange types, 
like IKE_SESSION_RESUME.

Thanks,
Tommy

> On Nov 12, 2018, at 6:07 AM, Valery Smyslov  wrote:
> 
> Hi,
> 
> I'm going to update IKE_AUX draft (in particular - change the way 
> it is authenticated based on recent discussion with Scott).
> 
> I recall that there were some complaints that the name IKE_AUX
> is not good because it can easily be mixed up with IKE_AUTH
> Actually, the phonetically close name was selected intentionally 
> to show that these exchanges are related. However, I'm not a native
> speaker and not always can realize how good or bad this similarity
> sounds for a native ear. 
> 
> So, my question to WG - do we need to change the name? If yes,
> then to what? Possible variants - IKE_INT (intermediate), IKE_PRE_AUTH. 
> Something else?
> 
> Regards,
> Valery.
> 
> ___
> 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] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes

[Tommy Pauly]

Agreed with Valery that this is a fine starting point to define the problem, 
but we will need to iterate on the details. 

I do support adoption. 

Thanks,
Tommy 

> On Oct 16, 2018, at 11:59 PM, Valery Smyslov  wrote:
> 
> Hi,
> 
> after reading the draft's introduction, I think the problem described
> is real. So I support adoption of this draft.
> 
> That said, it seems that the current draft solves the problem in 
> suboptimal way (too many new notifications defined), but that
> can be definitely discussed in the WG. And yes, I'm ready to 
> review the draft.
> 
> Regards,
> Valery.
> 
>> Our new charter has been approved and that includes item:
>> 
>>RFC7296 defines a generic notification code that is related to a
>>failure to handle an internal address failure. That code does not
>>explicitly allow an initiator to determine why a given address
>>family is not assigned, nor whether it should try using another
>>address family. The Working Group will specify a set of more
>>specific notification codes that will provide sufficient
>>information to the IKEv2 initiator about the encountered failure.
>>A possible starting pointing is
>>draft-boucadair-ipsecme-ipv6-ipv4-codes.
>> 
>> So this email will start one week long WG adoptation call for that
>> document [1] for WG adoptation.
>> 
>> Send your comments to this list before the 2018-10-21.
>> 
>> [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/
>> --
>> 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

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

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-tcp-guidelines-00.txt

[Tommy Pauly]

Hi Valery,

Thanks for sharing this!

I agree with the points you bring up for MOBIKE (not changing the message ID, 
and needing to recalculate NAT detection payloads). Those are useful to clarify.

Regarding retransmissions/puzzles/error handling, I agree with Paul that the 
recommendations being provided in your draft are potentially harmful to 
interoperability. We specifically did not include those in RFC8229 because it 
is not only possible, but likely, that some deployments will use TCP as a 
proxying layer that’s not directly implemented on the IKE endpoint, and that 
the IKE messages may be sometimes transmitted over both UDP and TCP (UDP behind 
TCP). This is, in fact, how we did our initial testing and bringup of the 
functionality.

Not retransmitting (or the other examples) assumes that the reliable link is 
end-to-end, even though that is not guaranteed or required by the spec. Can you 
clarify why an implementation would require modification of the protocol such 
that TCP encapsulation could not occur in a proxy? The one case I see is 
client-side MOBIKE, but I don’t think the server needs to do anything special 
(and clients that don’t want to do fancy MOBIKE fallback between UDP and TCP 
don’t need to change).

Thanks,
Tommy

> On Sep 7, 2018, at 7:18 AM, Valery Smyslov  wrote:
> 
> Hi Paul,
> 
>>> I've posted a draft with clarifications and implementation guidelines
>>> for RFC8229. These clarifications and recommendations are based
>>> on experience of implementing TCP encapsulation and testing it in
>>> various IKEv2 scenarios.
>>> 
>>> Feedback of any sort is highly appreciated.
>> 
>> I would cut a lot of the introduction / abstract and come straight to
>> the point. Simiarly, further one not provide as much details and just
>> come to the point faster.
> 
> I tried to be pedant :-) 
> 
>> I don't see any consideration in the document about deployments that
>> use a TCP proxy in front of the IKE daemon. In those scenarios, the
>> daemon might not even know TCP is used or the proxy code is written in
>> a way that only minimal changes to the IKEv2 core are needed. 
> 
> Is it ever possible? My experience shows that adding TCP encapsulation
> influences IKEv2 code pretty highly.
> 
>> So a lot of decisions you specify, such as not sending retransmits, might not
>> be possible for those kind of implementations, and so this document
>> dictating them for make interop harder, not easier.
> 
> Why? Can you clarify in which cases interop will be harder?
> 
>> As this also touches on message IDs, and I think we might have some
>> msgid deadlocks even in the UDP only case, perhaps a clarifying
> 
> If you mean MOBIKE, I agree with you that deadlocks seem to be possible.
> 
>> document could add some non-TCP items as well? And the TCP part could
>> be part of the new clarification draft ?
> 
> Not sure it's worth to mix them. 
> 
> Regards,
> Valery.
> 
>> 
>> Paul
>> 
>> ___
>> 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] Genart last call review of draft-ietf-ipsecme-split-dns-12

[Tommy Pauly]

Hi Christer,

Thanks for the review! Some responses inline.

Best,
Tommy

> On Aug 16, 2018, at 11:25 PM, Christer Holmberg 
>  wrote:
> 
> Reviewer: Christer Holmberg
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ipsecme-split-dns-12
> Reviewer: Christer Holmberg
> Review Date: 2018-08-16
> IETF LC End Date: 2018-08-24
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is well written, and almost ready for publication. I 
> have
> a couple of questions that I would like the authors to address.
> 
> Major issues: N/A
> 
> Minor issues:
> 
> Q1:
> 
> Section 3.1 contains some SHOULD-do statements, e.g.,:
> 
> "the initiator SHOULD also include one or more INTERNAL_IP4_DNS and
> INTERNAL_IP6_DNS attributes in the CFG_REQUEST"
> 
> "the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN attributes
> in the CFG_REQUEST."
> 
> Is there a reason for not using MUST instead of SHOULD?

In general, the CFG_REQUEST attributes are a bit loose—they're hints more than 
requirements.

From section 3.15.1 of RFC7296:

   The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
   information from its peer.  If an attribute in the CFG_REQUEST
   Configuration payload is not zero-length, it is taken as a suggestion
   for that attribute.  The CFG_REPLY Configuration payload MAY return
   that value, or a new one.  It MAY also add new attributes and not
   include some requested ones.  Unrecognized or unsupported attributes
   MUST be ignored in both requests and responses.

So, the CFG_REPLY MUST have a DNS server to go along with the DNS domain, but I 
left the SHOULD in spirit of the fact that the CFG_REQUEST is more of a 
suggestion.

That being said, if others in the WG would like to see this be a MUST, I'm fine 
with that as well. I don't think we should have the responder error out if it 
doesn't see both, however.


> 
> Q2:
> 
> Section 3.2 says:
> 
> "the initiator SHOULD behave as if Split DNS configurations are not supported
> by the server."
> 
> Again, is there a reason for not using MUST?

This one could be a MUST. The one exception I could see is if the initiator was 
statically configured with some split DNS domains to use as split domains
In case the responder didn't provide any in the CFG_REPLY, it should still use 
those and not send all DNS queries inside the tunnel. I wouldn't want this
MUST to disable the static configuration workarounds that implementations have 
done prior to allowing split DNS to be negotiated.

> 
> Nits/editorial comments:
> 
> Q3:
> 
> Is there a need for the "Background" section? Since the text is related to 
> what
> is described in the "Introduction", could the the text be moved there?

The main new points that the Background section adds on top of the Introduction 
are:
- The prior art for split DNS in IKEv1
- The fact that this is currently mainly seen in enterprise VPN deployments

These points could indeed be moved to the introduction. I had felt they fit 
better as "background" since they're not essential to the description of the 
protocol, but give context that is relevant now (and may be less so in the 
future).

> 
> 
> ___
> 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] I-D Action: draft-ietf-ipsecme-split-dns-11.txt

[Tommy Pauly]

> On Jul 22, 2018, at 12:01 PM, Paul Wouters  wrote:
> 
> On Thu, 19 Jul 2018, Tommy Pauly wrote:
> 
>>> Because you can have more then one INTERNAL_DNSSEC_TA for one domain.
>>> Instead, it should read:
>>> 
>>> Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an
>>> INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying to
>>> the same domain name MUST be ignored and treated as a protocol error.
>> 
>> Good point, agreed on this text.
>>> 
>>> From the previous diff, I'm confused about:
>>> 
>>> IKE clients MUST use a preconfigured whitelist of one or more domain
>>> which it will allow INTERNAL_DNSSEC_TA updates.
>>> 
>>> It could have an empty white list and use direct IP without split-dns ?
>>> Or use the VPN as an "encrypted DNS" provider for everything (which is
>>> allowed according to the spec, that is it does not violate a MUST NOT)
>>> 
>>> Also, since we allow signaling of "upgrade your IKE config out of band"
>>> if you see a new unconfigured domain name in the reply, it could be that
>>> you start with 0 and get a new one. Which also requires an empty list.
>> 
>> That's fair. Can you propose a sentence here to replace with?
> 
> How about:
> 
> IKE clients willing to accept INTERNAL_DNSSEC_TA updates MUST use a
> whitelist of one or more domains that can be updated. IKE clients with
> an empty whitelist MUST NOT accept any INTERNAL_DNSSEC_TA and MUST NOT
> use any INTERNAL_DNSSEC_TA received over IKE. Such clients MAY interpret
> receiving a INTERNAL_DNSSEC_TA for a non-whitelisted domain as a trigger
> to update their local configuration out of band.

That sounds fine to me.
> 
> the only issue left I see is that it is kind of weird that we would
> allow domain redirection (eg google.com to 192.168.1.1) but not
> INTERNAL_DNSSEC_TA redirection. So my question is still, should this
> whitelist text apply to INTERNAL_DNSSEC_TA or to both INTERNAL_DNS_DOMAIN
> and INTERNAL_DNSSEC_TA?

I'd rather not add this restriction to the normal DNS domain redirection, since 
claiming a DNS
domain for resolution does not imply changing the trust/validation properties 
of that domain.
Moreover, since by default, all DNS queries will be sent to the VPN's DNS 
server,
INTERNAL_DNS_DOMAIN strictly reduces the set of domains that will be resolved 
using
The VPN's DNS server. INTERNAL_DNSSEC_TA does add some new properties, and
thus is not merely a reduction.

Thanks,
Tommy

> 
> Paul

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt

[Tommy Pauly]

> On Jul 19, 2018, at 2:09 PM, Paul Wouters  wrote:
> 
> On Thu, 19 Jul 2018, internet-dra...@ietf.org wrote:
> 
>> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-11.txt
> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-11
> 
> This is probably wrong:
> 
>   Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an
>   INTERNAL_DNS_DOMAIN attribute MUST be ignored and treated as aprotocol 
> error.
> 
> Because you can have more then one INTERNAL_DNSSEC_TA for one domain.
> Instead, it should read:
> 
>   Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an
>   INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying to
>   the same domain name MUST be ignored and treated as a protocol error.

Good point, agreed on this text.
> 
> From the previous diff, I'm confused about:
> 
>   IKE clients MUST use a preconfigured whitelist of one or more domain
>   which it will allow INTERNAL_DNSSEC_TA updates.
> 
> It could have an empty white list and use direct IP without split-dns ?
> Or use the VPN as an "encrypted DNS" provider for everything (which is
> allowed according to the spec, that is it does not violate a MUST NOT)
> 
> Also, since we allow signaling of "upgrade your IKE config out of band"
> if you see a new unconfigured domain name in the reply, it could be that
> you start with 0 and get a new one. Which also requires an empty list.

That's fair. Can you propose a sentence here to replace with?

Tommy
> 
> Paul

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-10.txt

[Tommy Pauly]

> On Jul 18, 2018, at 4:35 PM, Waltermire, David A. (Fed) 
>  wrote:
> 
> I think the two "may" entries and the "should" in the following sentence 
> should be capitalized.

The "may" references are not intended to be capitalized MAYs; we are stating a 
fact (like "can"), since the normative language about the lists of domain 
requests comes above in the text. Specifying both a MAY and its opposite 
doesn't seem to add much textual value?

Similarly, the "should" that is not capitalized is not intended to be a 
normative command, but a description to introduce the following two normative 
statements.

IKE clients MUST use a preconfigured whitelist of one or more domain
   names for which it will allow INTERNAL_DNSSEC_TA updates.  This list
   may be sent in the CFG_REQUEST payload, or may be applied after
   reception of the CFG_REPLY payload.

   IKE clients should take care to only whitelist domains that apply to
   internal or managed domains, rather than to generic Internet traffic.
   The DNS root zone (".") MUST NOT be whitelisted.  Other generic or
   public domains, such as top-level domains, similarly SHOULD NOT be
   whitelisted.

> 
> Regards,
> Dave
> From: IPsec mailto:ipsec-boun...@ietf.org>> on 
> behalf of Tommy Pauly mailto:tpa...@apple.com>>
> Sent: Wednesday, July 18, 2018 4:28:30 PM
> To: IPsecME WG; Eric Rescorla
> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-10.txt
>  
> Hello all,
> 
> This new rev of the Split DNS document includes the feedback from our WG 
> discussion today for handling of the DNSSEC domain whitelist.
> 
> Please take a look! The document should be ready to progress at this point.
> 
> Best,
> Tommy
> 
> > On Jul 18, 2018, at 4:26 PM, internet-dra...@ietf.org 
> > <mailto:internet-dra...@ietf.org> wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the IP Security Maintenance and Extensions WG 
> > of the IETF.
> > 
> >Title   : Split DNS Configuration for IKEv2
> >Authors : Tommy Pauly
> >  Paul Wouters
> >Filename: draft-ietf-ipsecme-split-dns-10.txt
> >Pages   : 13
> >Date: 2018-07-18
> > 
> > Abstract:
> >   This document defines two Configuration Payload Attribute Types for
> >   the IKEv2 protocol that add support for private DNS domains.  These
> >   domains are intended to be resolved using DNS servers reachable
> >   through an IPsec connection, while leaving all other DNS resolution
> >   unchanged.  This approach of resolving a subset of domains using non-
> >   public DNS servers is referred to as "Split DNS"..
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ipsecme-split-dns%2Fdata=02%7C01%7Cdavid.waltermire%40nist.gov%7Cff7ef1c6c1be4bdf912608d5eced14e3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636675425355607080sdata=k%2F6Juy9hDJucBOTXoJgrwBeVfzw6iL3JcOsH1oP%2F4rk%3Dreserved=0
> >  
> > <https://na01.safelinks.protection.outlook.com/?url=https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/data=02|01|david.walterm...@nist.gov|ff7ef1c6c1be4bdf912608d5eced14e3|2ab5d82fd8fa4797a93e054655c61dec|1|0|636675425355607080sdata=k/6Juy9hDJucBOTXoJgrwBeVfzw6iL3JcOsH1oP/4rk=reserved=0>
> > 
> > There are also htmlized versions available at:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ipsecme-split-dns-10data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cff7ef1c6c1be4bdf912608d5eced14e3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636675425355607080sdata=anQJZuOh9jiwQY0DRjnkJF9t6rwoKUnCTkTtGD4pRjI%3Dreserved=0
> >  
> > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ipsecme-split-dns-10data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cff7ef1c6c1be4bdf912608d5eced14e3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636675425355607080sdata=anQJZuOh9jiwQY0DRjnkJF9t6rwoKUnCTkTtGD4pRjI%3Dreserved=0>
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ipsecme-split-dns-10data=02%7C01%7Cdavid.waltermire%40nist.gov%7Cff7ef1c6c1be4bdf912608d5eced14e3%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636675425355607080sdata=3%2FHdtPgHVzi%2B1gXSLO7m029WGCUJM2p0w940mZ8uH4I%3Dreserved=0
> >  
> > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org

Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-10.txt

[Tommy Pauly]

Hello all,

This new rev of the Split DNS document includes the feedback from our WG 
discussion today for handling of the DNSSEC domain whitelist.

Please take a look! The document should be ready to progress at this point.

Best,
Tommy

> On Jul 18, 2018, at 4:26 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions WG of 
> the IETF.
> 
>Title   : Split DNS Configuration for IKEv2
>    Authors : Tommy Pauly
>  Paul Wouters
>   Filename: draft-ietf-ipsecme-split-dns-10.txt
>   Pages   : 13
>   Date: 2018-07-18
> 
> Abstract:
>   This document defines two Configuration Payload Attribute Types for
>   the IKEv2 protocol that add support for private DNS domains.  These
>   domains are intended to be resolved using DNS servers reachable
>   through an IPsec connection, while leaving all other DNS resolution
>   unchanged.  This approach of resolving a subset of domains using non-
>   public DNS servers is referred to as "Split DNS".
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-10
> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-10
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-10
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] draft-pauly-ipsecme-split-dns

[Tommy Pauly]

It seems like the conversation here stalled out a bit.

From my perspective, the feeling in the working group is that the functionality 
described in the document for dealing with Split-DNS and DNSSEC is the best 
thing we can do given enterprise deployment models, as long as it is clear that 
client must validate TAs against configured local policy.

I think the text that Paul added recently does aim at clarifying this point. 
Are there specific nits or changes we want to see in the text there? I’d like 
to see this document be able to progress soon in a way that everyone is 
satisfied with.

Thanks,
Tommy

> On Jun 20, 2018, at 5:26 PM, Nico Williams  wrote:
> 
> On Thu, Jun 21, 2018 at 02:56:58AM +0300, Tero Kivinen wrote:
>> Nico Williams writes:
>>> On Wed, Jun 20, 2018 at 11:20:31PM +0300, Tero Kivinen wrote:
 So I think the feature that we can use TLSA records in the split-dns
 is very important. I agree that it would be VERY BAD for the client to
 just accept whatever domains server sends, and it SHOULD always verify
 it against its local configuration.
>>> 
>>> Agreed.
>>> 
>>> But I also think that a REQUIREMENT that the client support and check
>>> local policy as to which domains to accept TAs for is sufficient to
>>> address the concern.  Isn't it?
>> 
>> Yes and no.
>> 
>> Yes, I think that is best we can do.
>> 
>> [...]
> 
> Agreed.
> 
> Now, is the concern enough to reject this I-D?
> 
> Nico
> -- 

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

Re: [IPsec] RFC8229 (IKE over TCP) and retransmissions

[Tommy Pauly]

Hi Valery,

Thanks for bringing this up with the WG!

I agree that retransmissions of IKE packets within the TCP stream may be 
pointless, and add to congestion. We do mention this for ESP packets over the 
TCP stream (Section 12.2 Added Reliability for Unreliable Protocols), but it 
doesn’t call out IKE specifically.

Depending on how TCP encapsulation is implemented on each peer, it may be safe 
to assume that the entire end-to-end communication is reliable, but it may not 
be. In our testing of the protocol, we have placed boxes in front of IKEv2 
responders that handle the TCP encapsulation and translate them into UDP 
packets to pass on to the vanilla IKEv2 responder. In this case, the end-to-end 
reliability can’t be guaranteed, and the initiator of a message then may still 
need to retransmit IKE packets.

If we did want to add a recommendation here, I’d be tempted to say that an 
implementation should certainly be less aggressive with retransmissions in IKE, 
but may still send them if there is a lack of response from the remote peer. 
I’m not overly concerned with the impact of retransmitting IKE packets on the 
stream to overall tunnel performance, since these generally only account for a 
few packets.

Thanks,
Tommy

> On Apr 5, 2018, at 6:10 AM, Valery Smyslov  wrote:
> 
> Hi Tobias,
> 
>> Hi Valery,
>> 
>> I agree that generally retransmits are not useful or needed with TCP
>> encapsulation.  But as I see it, retransmits might actually be required
>> in some situations.  If the client sends e.g. a CREATE_CHILD_SA request
>> but the TCP connection is closed or gets unusable for some reason before
>> the server's response is received, the client has to reestablish the TCP
>> connection.  And the only way to do this (with window size 1, so no DPD
>> or MOBIKE update can be sent) is to send a retransmit of the already
>> sent message (otherwise the server might not know which TCP connection
> 
> That's why I suggested SHOULD :-)
> 
>> to use to send the CREATE_CHILD_SA response - I guess ESP packets could
>> be used for that too, if there are any and there is a way to get
>> notified in userland).  On the other hand, RFC 8229 explicitly says that
>> a responder should not consider retransmitted messages when deciding
>> which TCP connections should be used...so I guess there is no way to
>> recover properly if the TCP connection is severed mid-exchange (e.g.
>> because a NAT device is rebooted or the client device roams between
>> networks).
> 
> Yes, there may be situations which are difficult to recover from...
> 
> Regards,
> Valery.
> 
>> Regards,
>> Tobias
> 
> ___
> 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] Shepherd Review of draft-ietf-ipsecme-split-dns-06

[Tommy Pauly]

I as well have no IPR on this document and am not aware of any that exists.

Thanks,
Tommy

> On Mar 1, 2018, at 10:22 AM, Paul Wouters <p...@nohats.ca> wrote:
> 
> I have no IPR whatsoever on this document and don’t know of anyone who does
> 
> Sent from my iPhone
> 
>> On Mar 1, 2018, at 13:15, Waltermire, David A. (Fed) 
>> <david.walterm...@nist.gov> wrote:
>> 
>> Tommy and Paul,
>> 
>> I have the shepherd write-up ready.
>> 
>> Please confirm as authors that "any and all appropriate IPR disclosures 
>> required for full conformance with the provisions of BCP 78 and BCP 79 have 
>> already been filed."
>> 
>> I will send it forward once I hear from each of you.
>> 
>> Thanks,
>> Dave
>> 
>>> -Original Message-
>>> From: Paul Wouters [mailto:p...@nohats.ca]
>>> Sent: Wednesday, February 28, 2018 1:38 PM
>>> To: Tommy Pauly <tpa...@apple.com>
>>> Cc: Waltermire, David A. (Fed) <david.walterm...@nist.gov>; IPsecME WG
>>> <ipsec@ietf.org>; draft-ietf-ipsecme-split-dns.auth...@ietf.org
>>> Subject: Re: [IPsec] Shepherd Review of draft-ietf-ipsecme-split-dns-06
>>> 
>>>> On Wed, 28 Feb 2018, Tommy Pauly wrote:
>>>> 
>>>> I’ve updated the draft with your comments as version -
>>> 07: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>>> .ietf.org%2Fid%2Fdraft-ietf-ipsecme-split-dns-
>>> 07.txt=02%7C01%7Cdavid.waltermire%40nist.gov%7C7f9c42b6862143c
>>> e554d08d57eda625f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7
>>> C636554398785720298=IgghLE%2BFeO5%2B1Sti0QqzJKEogVgQ%2Ftle
>>> icvZExvDZ6Q%3D=0
>>> 
>>> Thanks for doing this. I would make one change (but it can be done after 
>>> IETF-
>>> LC)
>>> 
>>>   [...] the content SHOULD be considered untrusted and handled
>>> accordingly.
>>> 
>>> You changed should to SHOULD, but in this case it really is a MUST.
>>> 
>>> Paul
>> ___
>> 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] Shepherd Review of draft-ietf-ipsecme-split-dns-06

[Tommy Pauly]

Hi David,

I’ve updated the draft with your comments as version -07: 
https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt 
<https://www.ietf.org/id/draft-ietf-ipsecme-split-dns-07.txt>

Thanks,
Tommy

> On Feb 28, 2018, at 9:38 AM, Tommy Pauly <tpa...@apple.com> wrote:
> 
> Hi David,
> 
> Thanks! I’ll work on this today and send an update.
> 
> Tommy
> 
>> On Feb 26, 2018, at 4:51 PM, Waltermire, David A. (Fed) 
>> <david.walterm...@nist.gov> wrote:
>> 
>> Authors,
>> 
>> Overall the draft is almost ready to submit to the IESG once the following 
>> few small issues are resolved. 
>> 
>> Section 1.1:
>> 
>> There are a few lowercase instances of must, may, and should in the 
>> document. You should use text from RFC8174 to indicate that lowercase 
>> versions of the keywords are not normative.
>> 
>> Something like the following would work:
>> 
>>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>  "OPTIONAL" in this document are to be interpreted as described in BCP
>>  14 [RFC2119] [RFC8174] when, and only when, they appear in all
>>  capitals, as shown here.
>> 
>> Please double check the lowercase "must", "should", and "may" instances to 
>> be sure they are properly non-capitalized.
>> 
>> In section 3.1 the document states:
>> 
>> If an INTERNAL_DNSSEC_TA attriute is included
>>  in the CFG_REQUEST, the initiator SHOULD also include one or more
>>  INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST.
>> 
>> The behavior for the responder is not defined in section 3.2 if this 
>> "SHOULD" is violated. Would it be desireable for the responder to ignore the 
>> INTERNAL_DNSSEC_TA attribute? This behavior should be defined either way.
>> 
>> (nit) s/attriute/attribute/ (I think Tero already found this and we are 
>> waiting to handle this in AD review/IETF LC.)
>> 
>> Section 3.4.2:
>> 
>> (nit) s/attributes/attributes/
>> 
>> (nit) s/received in the CFG_REPLY/received in the CFG_REPLY./
>> 
>> "In this example, the initiator has no existing DNSSEC trust anchors would 
>> the requested domain." Should this be 'for the requested domain 
>> "example.com."'? The following sentence should start with a capitalized 
>> letter. The paragraph should end with a period.
>> 
>> How about the following as a replacement:
>> 
>> In this example, the initiator has no existing DNSSEC trust anchors
>>  for the requested domain "example.com". The responder provides DNSSEC
>>  trust anchors for the "example.com" domain, but does not configure trust 
>> anchors for the "city.other.com" domain.
>> 
>> Section 5:
>> 
>> The first sentence of the 6th paragraph contains a lowercase "must", which I 
>> believe should be capitalized.
>> 
>> (nit) s/be be/be/
>> 
>> Once this is all fixed I will send the draft to the IESG. I'll complete the 
>> writeup using your text as a starting point in the interim.
>> 
>> Regards,
>> Dave
>> 
>> ___
>> 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] Shepherd Review of draft-ietf-ipsecme-split-dns-06

[Tommy Pauly]

Hi David,

Thanks! I’ll work on this today and send an update.

Tommy

> On Feb 26, 2018, at 4:51 PM, Waltermire, David A. (Fed) 
>  wrote:
> 
> Authors,
> 
> Overall the draft is almost ready to submit to the IESG once the following 
> few small issues are resolved. 
> 
> Section 1.1:
> 
> There are a few lowercase instances of must, may, and should in the document. 
> You should use text from RFC8174 to indicate that lowercase versions of the 
> keywords are not normative.
> 
> Something like the following would work:
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>   "OPTIONAL" in this document are to be interpreted as described in BCP
>   14 [RFC2119] [RFC8174] when, and only when, they appear in all
>   capitals, as shown here.
> 
> Please double check the lowercase "must", "should", and "may" instances to be 
> sure they are properly non-capitalized.
> 
> In section 3.1 the document states:
> 
> If an INTERNAL_DNSSEC_TA attriute is included
>   in the CFG_REQUEST, the initiator SHOULD also include one or more
>   INTERNAL_DNS_DOMAIN attributes in the CFG_REQUEST.
> 
> The behavior for the responder is not defined in section 3.2 if this "SHOULD" 
> is violated. Would it be desireable for the responder to ignore the 
> INTERNAL_DNSSEC_TA attribute? This behavior should be defined either way.
> 
> (nit) s/attriute/attribute/ (I think Tero already found this and we are 
> waiting to handle this in AD review/IETF LC.)
> 
> Section 3.4.2:
> 
> (nit) s/attributes/attributes/
> 
> (nit) s/received in the CFG_REPLY/received in the CFG_REPLY./
> 
> "In this example, the initiator has no existing DNSSEC trust anchors would 
> the requested domain." Should this be 'for the requested domain 
> "example.com."'? The following sentence should start with a capitalized 
> letter. The paragraph should end with a period.
> 
> How about the following as a replacement:
> 
> In this example, the initiator has no existing DNSSEC trust anchors
>   for the requested domain "example.com". The responder provides DNSSEC
>   trust anchors for the "example.com" domain, but does not configure trust 
> anchors for the "city.other.com" domain.
> 
> Section 5:
> 
> The first sentence of the 6th paragraph contains a lowercase "must", which I 
> believe should be capitalized.
> 
> (nit) s/be be/be/
> 
> Once this is all fixed I will send the draft to the IESG. I'll complete the 
> writeup using your text as a starting point in the interim.
> 
> Regards,
> Dave
> 
> ___
> 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] Additional charter items 4/4: Mitigating privacy concerns

[Tommy Pauly]

+1 to adding privacy text to the charter. This seems like it will be 
increasingly relevant if we’re doing host-to-host communication and we want to 
protect the privacy of various peers.

—Tommy

> On Feb 16, 2018, at 12:09 PM, Paul Wouters  wrote:
> 
> On Fri, 16 Feb 2018, Tero Kivinen wrote:
> 
>> IKEv2 is currently vulnerable to the two following privacy concerns:
>> 
>> 1) It's not possible to run a server that obfuscates IKEv2/IPsec using
>>  TLS.
> 
>> 2) The privacy of the initiator's identity in the presence of a man in
>>  the middle attacker is not protected.
> 
>> Is this something that we should add to charter? Do people understand
>> the issue?
> 
> I would be in favour of adding this issue to the charter in some to be
> written text.
> 
> Paul
> 
> ___
> 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] qr-ikev2 interop test

[Tommy Pauly]

Thanks for setting this up! I'll try an interop soon (this week I hope).

However, some questions first: what values are you using for these?
- PPK_SUPPORT notify code
- PPK_IDENTITY notify code

Also, I presume you're using PPK_ID_FIXED, not PPK_ID_OPAQUE?

Thanks,
Tommy

> On Nov 13, 2017, at 6:05 PM, Paul Wouters  wrote:
> 
> 
> Some people were interested in interop for the ppk draft.
> 
> We have implemented draft-fluhrer-qr-ikev2, and are going to
> implement draft-ietf-ipsecme-qr-ikev2 in the near future.
> 
> To test, feel free to use the below server and let us know if you
> had positive or negative results:
> 
> server: vpn-ppk.nohats.ca
> server ID: GroupPPK1
> PSK: SecretPSK
> PPK ID: PPKID1
> static PPK: NotQuantumSafe
> 
> It is configured as an access VPN, so you will get an IP addres via CP to
> 0.0.0.0/0.
> 
> We are still working on cleaning up the code for dynamic PPK (OTP) support.
> 
> Paul & Vukasin
> 
> ___
> 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] Agenda for IETF 100

[Tommy Pauly]

+ 1 to these proposals

I'd also like to see the work on drafts like DIET-ESP 
(draft-mglt-ipsecme-diet-esp-04) be incorporated. I think we'll have some 
growing use cases for IPsec in constrained networks, and as that develops, 
extensions and modifications to the protocol to make IKEv2 and ESP work 
efficiently in those conditions will be necessary. (These would likely fall 
into the host-to-host use case described in the charter.)

Thanks,
Tommy

> On Oct 27, 2017, at 7:51 AM, Valery Smyslov  wrote:
> 
> Hi,
> 
> I think that the following items can be considered for the new charter.
> 
> 1. Develop load sharing cluster solution for IKEv2/IPsec. The possible 
> charter text:
> 
>   MOBIKE protocol [RFC4555] is used to move existing
>   IKE/IPsec SA from one IP address to another. However,
>   in MOBIKE it is the initiator of the IKE SA (i.e. remote access client)
>   that controls this process. If there are several responders 
>   each having own IP address and acting together as a load sharing 
> cluster,
>   then it is desirable for them to have ability to request initiator to 
> switch to 
>   a particularmember. The working group will analyze the possibility
>   to extend MOBIKE protocol or to develop new IKE extension
>   that will allow to build load sharing clusters in an interoperable way.
> 
> 2. Make IKEv2 Postquantum Cryptography ready. In particular - make it
>able to transfer large payloads in initial exchange without having
>IP fragmentation issues. The possible charter text:
> 
>   Postquantum Cryptography brings new key exchange methods.
>   Most of these methods that are known to date have much larger public
>   keys then conventional Diffie-Hellman public keys. Direct using
>   these methods in IKEv2 might lead to a number of problems
>   due to the increased size of initial IKEv2 messages. The working group 
> will 
>   analyze the possible problems and develop a solution, that will
>   make adding Postquantum key exchange methods more easy.
> 
> Regards,
> Valery.
> 
> 
>> We will be meeting at Monday morning 09:30-11:00 for 1.5 hours. Our
>> main agenda item will be the rechartering text, i.e., our charter will
>> expire by the end of year, and we have most of our chartered work
>> already completed, or almost finished, so we need to decide what new
>> items (if any) we take to our charter, or wheter we shut down the WG.
>> 
>> In last IETF we had people with items which we could add to charter,
>> so I want those people wanting to add things to charter to send an
>> email to the mailing list about what items they would like to propose
>> to the charter, and preliminary charter text for the item.
>> 
>> If we do not receive any proposed charter texts, then I assume we do
>> not have any more work to do after we finish our current charter...
>> 
>> Also if there is people wanting to present anything in the next
>> IPsecME IETF session, send email to wg chairs ipsecme-cha...@ietf.org.
>> --
>> 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

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

Re: [IPsec] Should draft-ietf-ipsecme-tcp-encaps-10 update 7296 ?

[Tommy Pauly]

> On Jun 1, 2017, at 4:17 PM, Paul Wouters <p...@nohats.ca> wrote:
> 
> On Wed, 31 May 2017, Tommy Pauly wrote:
> 
>> I've posted a new version of the draft that incorporates the changes 
>> discussed in this thread. Please review!
>> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10
> 
> I just noticed this in RFC 7296:
> 
>   However, if a NAT is detected, both devices MUST use UDP encapsulation 
> for ESP.
> 
> I'm not sure if this one sentence really qualifies as this draft needing
> a formal "Updates 7296", but it currently does not seem to do that.

Technically, one should only do TCP encapsulation if UDP couldn't go through at 
all—so you couldn't even get the IKE_SA_INIT response to do NAT detection. That 
means that we aren't in this case. However, I'm happy to add a line to clarify 
this if we'd prefer that =)

Thanks,
Tommy

> 
> Paul

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

Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tommy Pauly]

Hello,

I've posted a new version of the draft that incorporates the changes discussed 
in this thread. Please review!

https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10 
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10>

Thanks,
Tommy


> On May 12, 2017, at 3:25 PM, Tommy Pauly <tpa...@apple.com> wrote:
> 
> 
> 
>> On May 8, 2017, at 5:49 AM, Mirja Kuehlewind (IETF) <i...@kuehlewind.net> 
>> wrote:
>> 
>> Does the proposed text changes from Tommy still refer to 443 anywhere (lost 
>> track a bit but I guess the appendix still does right)?
>> 
>> Again I think we should talk about using 443 if that’s what’s done in 
>> reality. However my understanding is that real-life implementation use 
>> TCP/TLS which I think could be discussed in the body rather than the 
>> appendix.
> 
> The current state will not refer to 443 in the body, but specify TCP 4500, 
> with the option to have both peers mutually agree on another port to use if 
> necessary. The working group had felt that bringing TLS over 443 directly 
> into the body would be inappropriate for the standard. We mention in the 
> discussion of previous solutions that there are "SSL VPNs", which covers the 
> current reality of how the problem is solved.
> 
>> 
>> And I would like to see a recommendation that HTTPS and TCPIKE should not be 
>> multiplexed the same time on the same port. My understanding from Tero’s 
>> feedback was that this is usually not done today and probably not necessary 
>> in future.
> 
> Yes, I think it makes sense to add to the text around the configuration that 
> it is recommended to not run any other service on the same port as TCP 
> Encapsulated IPsec.
> 
> Thanks,
> Tommy
> 
>> 
>> Mirja
>> 
>> 
>>> Am 05.05.2017 um 23:13 schrieb Eric Rescorla <e...@rtfm.com>:
>>> 
>>> It seems like most of the issues are resolved here, except for that of 
>>> muxing
>>> IKE and non-IKE protocols on the same port (especially 443). My 
>>> understanding
>>> is that (although we may not like it) it's nevertheless a common practice, 
>>> and
>>> yet we can't levy the requirement that no other protocol start with 
>>> IKETCP,
>>> so it seems like what we need is a warning note and potentially a request 
>>> to reserve
>>> this string for some set of common protocols (HTTP,...?).
>>> 
>>> Mirja, would that work for you?
>>> 
>>> -Ekr
>>> 
>>> 
>>> On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF 
>>> <spencerdawkins.i...@gmail.com> wrote:
>>> 
>>> 
>>> On May 3, 2017 05:54, "Mirja Kühlewind" <i...@kuehlewind.net> wrote:
>>> I didn't propose to obsolete RFC3947 in this document. I guess you can also 
>>> file an error for this if you don't want to take any further actions. 
>>> However, for updating the IANA registry, I would say the right action is to 
>>> do this simply by IESG approval for UDP then.
>>> 
>>> Fwiw, that would work for me.
>>> 
>>> Spencer
>>> 
>>> 
>>> 
>>> Mirja
>>> 
>>> 
>>> 
>>> On 03.05.2017 11:12, Tero Kivinen wrote:
>>> Mirja Kuehlewind (IETF) writes:
>>> my thinking was that the main problem is that 3947 was not obsoleted
>>> and I’m assuming we need a document to fix that.
>>> 
>>> This is partly issue, but it is not issue we need to solve here, as
>>> this document is not something that should obsolete 3947.
>>> 
>>> Also 3947 only defines extension for the IKEv1 (RFC2409) and that is
>>> already obsoleted, so effectively RFC3947 is already obsoleted, as
>>> there is no way to implement 3947 without implementing obsoleted
>>> protocol...
>>> 
>>> This issue is not not important enough to require RFC now.
>>> 
>>> In this case that document could/should also fix the IANA entry for
>>> the UDP port. However, I’m actually not sure what the right
>>> processing would be to fix this forgotten obsolete… maybe other ADs
>>> know better…?
>>> 
>>> For now I would just leave it as it is, but fix the references in the
>>> IANA registry so that document will not be referenced, especially as
>>> the original IANA reference was not to the correct RFC in the first
>>> place.
>>> 
>>> Otherwise if you don’t want to do this, I don’t think it’s a good
>>> idea to merge kind of unrelated fixes into this spec. We can also
>>> fix that by using the IESG approval process (see RFC5226). I think
>>> that’s the better option!
>>> 
>>> That is true, but as this document already modifies the TCP/4500
>>> reference, fixing the UDP/4500 reference at the same time is not
>>> completely unrelated fix.
>>> 
>>> Obsoleting RFC3947 would be unrelated fix.
>>> 
>>> 
>>> 
>> 
> 

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

Re: [IPsec] Question about ipsecme-tcp-encaps

[Tommy Pauly]

> On May 17, 2017, at 12:12 PM, Scott Fluhrer (sfluhrer)  
> wrote:
> 
>  
> From: Yoav Nir [mailto:ynir.i...@gmail.com ] 
> Sent: Wednesday, May 17, 2017 2:54 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: IPsecme WG (ipsec@ietf.org )
> Subject: Re: [IPsec] Question about ipsecme-tcp-encaps
>  
>  
> On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer)  > wrote:
>  
> I’ve been looking over the draft, and I think I see a potential DoS attack 
> that does not appear to be addressed.  I’m writing this to see if there is 
> something I missed (and if there isn’t, start discussion on how we might 
> patch things up).
>  
> This is the scenario I’m looking at: Alice and Bob have a TCP-based IKE/IPsec 
> connection established.
>  
> Then, Eve injects a TCP packet to Bob with Alice’s source IP (and with the 
> appropriate TCP sequence numbers), and whose body consists of a single FF 
> byte.  Eve does nothing else than that (other than possibly absorbing the 
> TCP-ACK that Bob would send out, if that’d confuse Alice’s TCP stack…)
>  
> Alice will then send a legitimate packet, consisting of (for example) [Length 
> = 0x0124] [ESP Header][Body].  However, Bob’s TCP stack thinks it has already 
> received the first byte, and so it’ll ignore it, and so will tell the 
> application (IPsec) that it has received [0xff34][ESP Header][Body].
>  
> My TCP may be rusty, but I think Alice’s legitimate packet has the sequence 
> number to indicate it is retransmitting the byte that Bob already has. I 
> don’t know if that means that the new data overwrites the old data, that the 
> old data remains, of that the stack checks that it matches.
>  
> I don’t think it’s defined within TCP (rather, it’s up to the individual 
> stack); on the other hand, in general, the TCP stack has already handed off 
> the byte to the application (the IPsec packet stream parser), and so it 
> *can’t* overwrite it.
>  
> Of course, we could say “Eve modifies a valid TCP-encapsulated IPsec packet 
> so that the first byte is 0xff”, and we have the same attack…
> 
> 
> The IPsec packet parsing code would interpret this as an extremely long 
> encrypted packet, and so will continue to absorb the next 0xfe00 bytes from 
> Alice.
>  
> It’ll then try to decrypt it; it’ll fail.  That, in itself, is not that big 
> of a deal; we assume that an attacker who can modify packets at will is able 
> to force a few packets to be dropped.
>  
> However, look what happens after that; the IPsec stream parsing code will 
> then take the next two bytes of the stream, and try to parse them as ‘packet 
> length’.  We stopped at a random location within the TCP stream, and so quite 
> likely, we’re in the middle of an encrypted packet, and so the length will be 
> a random value.  We’ll then try to parse the next bytes as a packet, and this 
> will keep on going (blocking all Alice -> Bob traffic) until the 
> end-of-packet the IPsec stream parser assumes just happens to fall on an 
> actual packet boundary – obviously, that might be a while.
>  
> I agree. Once synchronization is lost, it may as well never be regained.
> 
> 
> TLS uses a similar ‘record lengths appear in the TCP stream’ concept; however 
> in the case of TLS, on decryption failure, you MUST close the connection (and 
> so this repeated ‘get a random sequence of bytes and try to decrypt’ isn’t an 
> issue); I didn’t see a similar mandate in the IPsec draft.
>  
>  
> Was there something I missed?  The draft does have the text:
>  
>If either TCP Originator or TCP Responder
>receives a stream that cannot be parsed correctly (for example, if
>the TCP Originator stream is missing the stream prefix, or message
>frames are not parsable as IKE or ESP messages), it MUST close the
>TCP connection.
>  
> However:
> a)  That’s in a paragraph that starts “If a TCP connection is being used 
> to resume a previous IKE session…”; does it apply only in that case?

No, the MUST close applies for all connections, regardless of resumption. We 
could add a paragraph break to make that explicit.

> b)  An ESP message is of the form [SPI][Sequence number][Random bytes]; 
> unless you happen to get a SPI < 256 or length < 8, it’s not clear how you 
> could get something that is not of that format (unless you mandate that the 
> ESP length must be a multiple of 4 bytes; in that case, you should state that 
> explicitly)

My assumption was that receiving an unknown SPI would automatically cause the 
parsing to fail as a valid ESP message. I can add that to the text. Adding 
bytes to the stream would shift the valid SPI. Beyond that, as you mention the 
packet would not be decryptable, and certainly the next bytes after the invalid 
frame's length would not parse as a valid SPI. The reading would stop by then 
at least. We can also recommended that readers enforce a sane limit on 

Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tommy Pauly]

> On May 8, 2017, at 5:49 AM, Mirja Kuehlewind (IETF)  
> wrote:
> 
> Does the proposed text changes from Tommy still refer to 443 anywhere (lost 
> track a bit but I guess the appendix still does right)?
> 
> Again I think we should talk about using 443 if that’s what’s done in 
> reality. However my understanding is that real-life implementation use 
> TCP/TLS which I think could be discussed in the body rather than the appendix.

The current state will not refer to 443 in the body, but specify TCP 4500, with 
the option to have both peers mutually agree on another port to use if 
necessary. The working group had felt that bringing TLS over 443 directly into 
the body would be inappropriate for the standard. We mention in the discussion 
of previous solutions that there are "SSL VPNs", which covers the current 
reality of how the problem is solved.

> 
> And I would like to see a recommendation that HTTPS and TCPIKE should not be 
> multiplexed the same time on the same port. My understanding from Tero’s 
> feedback was that this is usually not done today and probably not necessary 
> in future.

Yes, I think it makes sense to add to the text around the configuration that it 
is recommended to not run any other service on the same port as TCP 
Encapsulated IPsec.

Thanks,
Tommy

> 
> Mirja
> 
> 
>> Am 05.05.2017 um 23:13 schrieb Eric Rescorla :
>> 
>> It seems like most of the issues are resolved here, except for that of muxing
>> IKE and non-IKE protocols on the same port (especially 443). My understanding
>> is that (although we may not like it) it's nevertheless a common practice, 
>> and
>> yet we can't levy the requirement that no other protocol start with 
>> IKETCP,
>> so it seems like what we need is a warning note and potentially a request to 
>> reserve
>> this string for some set of common protocols (HTTP,...?).
>> 
>> Mirja, would that work for you?
>> 
>> -Ekr
>> 
>> 
>> On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF 
>>  wrote:
>> 
>> 
>> On May 3, 2017 05:54, "Mirja Kühlewind"  wrote:
>> I didn't propose to obsolete RFC3947 in this document. I guess you can also 
>> file an error for this if you don't want to take any further actions. 
>> However, for updating the IANA registry, I would say the right action is to 
>> do this simply by IESG approval for UDP then.
>> 
>> Fwiw, that would work for me.
>> 
>> Spencer
>> 
>> 
>> 
>> Mirja
>> 
>> 
>> 
>> On 03.05.2017 11:12, Tero Kivinen wrote:
>> Mirja Kuehlewind (IETF) writes:
>> my thinking was that the main problem is that 3947 was not obsoleted
>> and I’m assuming we need a document to fix that.
>> 
>> This is partly issue, but it is not issue we need to solve here, as
>> this document is not something that should obsolete 3947.
>> 
>> Also 3947 only defines extension for the IKEv1 (RFC2409) and that is
>> already obsoleted, so effectively RFC3947 is already obsoleted, as
>> there is no way to implement 3947 without implementing obsoleted
>> protocol...
>> 
>> This issue is not not important enough to require RFC now.
>> 
>> In this case that document could/should also fix the IANA entry for
>> the UDP port. However, I’m actually not sure what the right
>> processing would be to fix this forgotten obsolete… maybe other ADs
>> know better…?
>> 
>> For now I would just leave it as it is, but fix the references in the
>> IANA registry so that document will not be referenced, especially as
>> the original IANA reference was not to the correct RFC in the first
>> place.
>> 
>> Otherwise if you don’t want to do this, I don’t think it’s a good
>> idea to merge kind of unrelated fixes into this spec. We can also
>> fix that by using the IESG approval process (see RFC5226). I think
>> that’s the better option!
>> 
>> That is true, but as this document already modifies the TCP/4500
>> reference, fixing the UDP/4500 reference at the same time is not
>> completely unrelated fix.
>> 
>> Obsoleting RFC3947 would be unrelated fix.
>> 
>> 
>> 
> 

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

Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tommy Pauly]

I'll defer to Tero on this one. Tero, what do you prefer to do with the IANA 
Considerations text?

Thanks,
Tommy

> On Apr 28, 2017, at 4:41 PM, Spencer Dawkins at IETF 
> <spencerdawkins.i...@gmail.com> wrote:
> 
> This is still Mirja's Discuss (which I supported), so I'll let her respond to 
> most of Tommy's proposed text changes, but on the last one ...
> 
> On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly <tpa...@apple.com 
> <mailto:tpa...@apple.com>> wrote:
> 
> 14.  IANA Considerations
> 
>This memo includes no request to IANA.
> 
>TCP port 4500 is already allocated to IPsec for NAT Traversal.  This port 
> SHOULD
>be used for TCP encapsulated IKE and ESP as described in this document.
> 
> With no IANA actions, the entry in 
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4500
>  
> <https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4500>
>  for 4500/tcp will still point to http://www.iana.org/go/rfc3947 
> <http://www.iana.org/go/rfc3947> as the reference. 
> 
> Should that change when this draft is published?
> 
> Thanks,
> 
> Spencer, who may be confused, but wanted to ask before the draft is approved

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

Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tommy Pauly]

Hello all,

Here's some proposed text for:

- Clarifying the configuration model around ports
- Clarifying the role of the stream prefix
- Expanding the TCP performance considerations. 

Changes are in bold.

Thanks,
Tommy

---

2.  Configuration

   One of the main reasons to use TCP encapsulation is that UDP traffic
   may be entirely blocked on a network.  Because of this, support for
   TCP encapsulation is not specifically negotiated in the IKE exchange.
   Instead, support for TCP encapsulation must be pre-configured on both
   the TCP Originator and the TCP Responder.

   Implementations MUST support TCP encapsulation on TCP port 4500, 
   which is reserved for IPsec NAT Traversal. 

   Beyond a flag indicating support for TCP encapsulation, the configuration
   defined on each peer can include the following optional parameters:

   o  Alternate TCP ports on which the specific TCP Responder listens for
  incoming connections.  Note that the TCP Originator may initiate
  TCP connections to the TCP Responder from any local port. 

  ...

4.  TCP-Encapsulated Stream Prefix

   Each stream of bytes used for IKE and IPsec encapsulation MUST begin
   with a fixed sequence of six bytes as a magic value, containing the
   characters "IKETCP" as ASCII values.  This value is intended to identify
   and validate that the TCP connection is being used for TCP encapsulation
   as defined in this document, to avoid conflicts with the prevalence of 
previous
   non-standard protocols that used TCP port 4500. This value is only sent 
once, 
   by the TCP Originator only, at the beginning of any stream of IKE and ESP 
messages.

...

12.  Performance Considerations

   Several aspects of TCP encapsulation for IKE and IPsec packets may
   negatively impact the performance of connections within a tunnel-mode
   IPsec SA.  Implementations should be aware of these and take these
   into consideration when determining when to use TCP encapsulation.
   Due to these performance impacts, implementations SHOULD favor using 
   direct ESP or UDP encapsulation over TCP encapsulation whenever
   possible.


12.1.  TCP-in-TCP

   If the outer connection between IKE peers is over TCP, inner TCP
   connections may suffer effects from using TCP within TCP.  Running
   TCP within TCP is discouraged, since the TCP algorithms
   generally assume that they are running over an unreliable datagram
   layer.

   If the outer (tunnel) TCP connection experiences packet loss, this loss
   will be hidden from any inner TCP connections, since the outer connection
   will retransmit to account for the losses. This means that loss on an outer 
   connection will be interpreted only as delay by inner connections. Since
   the outer TCP connection will deliver the inner messages in order, any 
messages
   after a lost packet may have to wait until the loss is recovered. This 
increases
   the burstiness of inner traffic, since a large number of inner packets will 
be delivered
   across the tunnel at once. This effect is especially of concern when there 
is a high 
   level of loss on the outer connection.

   TCP-in-TCP can also lead to increased buffering, or bufferbloat. This can 
occur when the
   window size of the outer TCP connection is reduced, and becomes smaller than 
the window
   sizes of the inner TCP connections. This can lead to packets backing up in 
the outer TCP
   connection's send buffers. In order to limit this effect, the outer TCP 
connection should have
   limits on its send buffer size, and on the rate at which it reduces its 
window size.

   The inner TCP's round-trip-time estimation will also be affected by the 
burstiness of the outer 
   TCP connection.  This will make loss-recovery of the inner TCP traffic less 
reactive and more
   prone to spurious retransmission timeouts.

   Note that any negative effects will be shared between all flows going 
through the outer TCP
   connection. This is of particular concern for any latency-sensitive or 
real-time applications 
   using the tunnel. If such traffic is using a TCP encapsulated IPsec 
connection, it is recommended
   that the number of inner connections sharing the tunnel be limited as much 
as possible.

...

12.5.  Tunnelling ECN in TCP

   Since there is not a one-to-one mapping between outer IP packets and inner 
ESP/IP messages
   when using TCP encapsulation, the markings for Explicit Congestion 
Notification (ECN) cannot
   be simply mapped. However, any ECN markings on inner messages should be 
preserved through
   the tunnel.

   Implementations SHOULD follow the ECN compatibility mode as described in RFC 
6040. The
   outer TCP connection SHOULD mark its packets as not ECN-capable, but SHOULD 
NOT clear
   any ECN markings on inner packets.

...

14.  IANA Considerations

   This memo includes no request to IANA.

   TCP port 4500 is already allocated to IPsec for NAT Traversal.  This port 
SHOULD
   be used for TCP encapsulated IKE and ESP 

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tommy Pauly]

> On Apr 27, 2017, at 7:32 AM, Mirja Kühlewind  wrote:
> 
> See below
> 
> On 27.04.2017 16:27, Eric Rescorla wrote:
>> 
>>"This document leaves the selection of TCP ports up to
>>   implementations.  It is suggested to use TCP port 4500, which 
>> is
>>   allocated for IPsec NAT Traversal."
>> 
>>Which sounds to me like an invitation to squat on any open port
>>regardless what the port is supposed to be used for (hoping that 
>> the
>>magic number would avoid any collision). I don't think that a
>>good thing
>>to right in an RFC.
>> 
>> 
>>Hmm... Maybe I don't understand your overall theory here. It seems
>>like having
>>reserved ports for protocols but letting people run them on any port
>>they want
>>to is kind of common practice. See, for instance:
>>https://tools.ietf.org/html/rfc7230#section-2.7.1
>>
>> 
>>"  If the host identifier is provided as an IP address, the origin
>>   server is the listener (if any) on the indicated TCP port at that 
>> IP
>>   address. If host is a registered name, the registered name is an
>>   indirect identifier for use with a name resolution service, such as
>>   DNS, to find an address for that origin server. If the port
>>   subcomponent is empty or not given, TCP port 80 (the reserved port
>>   for WWW services) is the default."
>> 
>> 
>>This doesn't say you can/should use any port you want (it says you can
>>use another port than 80) but you should till avoid to use any other port
>>that runs a different TCP service.
>> 
>> 
>> Well, that may be part of your background assumptions, but the document
>> doesn't say that. It just tells you how to use a different port and is 
>> silent on
>> what port you should use.
>> 
> 
> That's what we have the registry for. The difference is, it's okay to use a 
> random port (instead of one specific reserved one) but this draft explicitly 
> is intended to use other reserved ports.

The only recommended port in the draft is 4500, which is what is reserved in 
the registry. The use of any other port is by configuration only. As Tero and 
others have explained, all IKE connections are made to pre-known pre-configured 
hosts. All the IKE implementations I am aware of allow the useable IKE ports to 
be customized.

I'm fine removing any mention of other specific ports, even in the appendix. 
However, the fact that configurations can choose what ports to use is something 
that needs to be left open. The point of the port registry is to allow devices 
to expect what service will be offered on a given port when they connect. If 
two peers mutually decide to share their own configuration, they can do that.

Thanks,
Tommy

> 
> Mirja
> 
> 
> ___
> 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] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tommy Pauly]

> On Apr 27, 2017, at 6:46 AM, Mirja Kühlewind  wrote:
> 
> One more side comment on the magic number: actually the magic number makes it 
> easy for network operator to identify IKE/IPSec traffic on any port and block 
> all packets that below to a flow that started with this pattern in the first 
> payload packet. So if you really think you need a magic number, you should 
> probably always encrypt it.

The working group determined that the point of the protocol is not to evade any 
possibility for middleboxes to block the traffic, but instead to allow 
connectivity through middle boxes that are essentially 'accidentally' blocking 
IKE/ESP. If an operator wants to block this traffic explicitly, that is fine. 
However, it is very common that networks on public access points will block 
everything by default based on what they consider to be 'web' traffic; they do 
not inspect more deeply.

Thanks,
Tommy

> 
> 
> 
> On 27.04.2017 15:42, Mirja Kühlewind wrote:
>> Hi Ekr, hi all,
>> 
>> (not sure anymore which email best to reply to but I'm using this one now to
>> partly also reply to others).
>> 
>> See below.
>> 
>> On 27.04.2017 14:51, Eric Rescorla wrote:
>>> 
>>> 
>>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind >> > wrote:
>>> 
>>>I do see the problem you have and I understand why you selected the
>>>solution you have but that does contradict quite a bit the idea of the
>>>port registry and I don't think it's a safe and future prove solution.
>>>Even if people use this approach, I'm concern to publish it in an
>>>Standards Track RFC, but I guess that's a discussion the IESG would need
>>>to have.
>>> 
>>> 
>>> Mirja,
>>> 
>>> I agree that this kind of port squatting is regrettable, but I also don't
>>> think it really
>>> helps to not publish RFCs that document widely used protocols because we
>>> are sad they port-squatted.
>>> 
>>> I proposed a way to deal with this in an earlier e-mail. Would that be
>>> satisfactory
>>> to you. To retransmit, we add the following
>>> 
>>> "Note: While port 4500 is the reserved port for this protocol, some existing
>>> implementations
>>> also use port 443. The Stream Prefix provides some mitigation against
>>> cross-protocol
>>> attacks in this case, however, the use of port 443 is NOT RECOMMENDED"
>>> 
>>> We could do something similar for port 80.
>>> 
>>> Would that work?
>> 
>> This already is good but I think it's not enough. As Tero noted the working
>> group thought that they rather specify a generic scheme which I find
>> problematic. Currently the drafts says:
>> 
>> "This document leaves the selection of TCP ports up to
>>implementations.  It is suggested to use TCP port 4500, which is
>>allocated for IPsec NAT Traversal."
>> 
>> Which sounds to me like an invitation to squat on any open port regardless
>> what the port is supposed to be used for (hoping that the magic number would
>> avoid any collision). I don't think that a good thing to right in an RFC.
>> 
>> Now given the text you propose above, I actually assume that the text I just
>> cited will be removed but the whole document is written with this assumption
>> and therefore there are a couple more places where wording probably needs to
>> change.
>> 
>> I do understand well the problem and that 443 is used in practice. However,
>> to match reality I would rather like to see a document that specifies the
>> approach of encapsulating in TLS/TCP on port 443 that is used today and pure
>> TCP encapsulation for use with port 4500 only. Again i think that's where
>> your proposed text is heading to but I think it needs more changes; in this
>> case it would also make sense to add the TLS part back in the main document
>> for 443 only.
>> 
>> Further, I have one more question: The document is written in a way that
>> allows the implementation of multiple services on the used port. Is that
>> actually done in reality? If we could restrict the use of this encapsulation
>> with servers that only are IKE servers (at least for the used port), you
>> would actually not need the magic number anymore. I guess you can still have
>> the magic number if you really want it because that makes it easier to
>> distinguish valid IKE/IPSec traffic from other random traffic that might be
>> send to this port but the other service running on this port (on other
>> servers) does not need to know about the magic number because it is supposed
>> to never see any IKe/IPSec TCP-encapsulated traffic.
>> 
>> Does that make sense?
>> 
>> Mirja
>> 
>> 
>> 
>>> 
>>> -Ekr
>>> 
>>> 
>>> 
>>> 
>>>Mirja
>>> 
>>> 
>>> 
>>>We can soften the references in the appendix to the fact that other
>>>ports may, in fact, be used. As for the configuration, it should
>>>state 4500 as the default, but allow peers to configure something
>>>else out-of-band if they want to modify behavior (which is 

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tommy Pauly]

> On Apr 26, 2017, at 12:51 PM, Eric Rescorla <e...@rtfm.com> wrote:
> 
> AFAICT there are two separate issues:
> 
> - The use of 4500, which, as Tero says, we can just update the registry to 
> point to this document for.
> - The use of 443, which seems more complicated
> 
> WRT 443, I would assert the following facts:
> 
> - It's not awesome that people use 443 (though understandable because of 
> overly-aggressive firewalls)
> - People aren't going to stop using 443 (because it goes through NATs well)
> 
> Generally, I think it's more useful for documents to reflect reality, even if 
> we don't like that reality,
> and 443 only appears in the appendix, so that seems fairly innocuous to me. 
> Perhaps we can
> leave the 443 in the appendix with some note like:
> 
> "Note: While port 4500 is the reserved port for this protocol, some existing 
> implementations
> also use port 443. The Stream Prefix provides some mitigation against 
> cross-protocol
> attacks in this case, however, the use of port 443 is NOT RECOMMENDED"
> 
> What would people think about that?

That sounds good to me. I think we may want to mention that the Stream Prefix 
is used to distinguish from any other protocols running on port 4500, etc, not 
really specifically to 443.

> 
> Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be 
> wiggle room
> to specify ALPN here? Or maybe a longer prefix?

The document's text regarding ALPN is in section 4:

"Although some framing protocols do support negotiating inner protocols, the 
stream prefix should always be used in order for implementations to be as 
generic as possible and not rely on other framing protocols on top of TCP."

The idea is that we don't want to use TLS as a wrapper whenever possible. An 
implementation on an IKE server may be behind a proxy or another process that's 
terminating the TLS or raw TCP, and passing the inner stream along. In that 
case, we wanted a standard way to put IKE and ESP in a stream, not relying on 
an outer protocol's details.

I'm perfectly open to using another prefix value; if you have a suggestion for 
a longer value, that would be great!

Thanks,
Tommy

> 
> -Ekr
> 
> 
> On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen <kivi...@iki.fi 
> <mailto:kivi...@iki.fi>> wrote:
> Tommy Pauly writes:
> > > --
> > > DISCUSS:
> > > --
> > >
> > > This draft suggests that ports that are assigned to other services can
> > > simply be used. This is not okay. If a port is assigned to a certain
> > > service, this service and/or the respective RFC defines how this port is
> > > used. Simply changing the specified behavior by requiring a check for a
> > > magic number cannot be done without updating the RFC that the port
> > > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
> > > the IANA registry would need to be updated.
> >
> > At this point, the only portion of the document that mentions a port
> > other than 500 and 4500 is the appendix. We recommend that 4500 is
> > used as the port for TCP encapsulation. The IANA registry for
> > 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947;
> > that document does not explain how TCP is to be used, so the
> > reference should be updated to point to the document on TCP
> > encapsulation.
> 
> I already explained this in long email to the Joe and Paul, but
> noticed that those emails did not go to to the IESG, so this is mostly
> cut & paste of my previous email. This does not cover anything about
> using any other ports, but covers the case about the IANA allocations
> for TCP/4500 and UPD/4500.
> 
> --
> Paul Wouters writes:
> > On Tue, 25 Apr 2017, Joe Touch wrote:
> > > Every bit pattern, including those using magic numbers, is already
> > > owned and under the control of each assigned port. It is not
> > > appropriate for any new service to hijack that pattern as having a
> > > different meaning UNLESS explicitly updating the service on
> > > that port.
> > >
> > > A simple summary of what needs to change, in 2119-language:
> > >
> > >- this approach MUST NOT be described as applying to any
> > >  assigned number unless also updating the associated RFC
> >
> > So it should add an Updates: RFC-3947
> 
> Not really. It does not update RFC3947 as it does not change the
> obsoleted protocol defined in the RFC3947. 

Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT)

[Tommy Pauly]

> On Apr 26, 2017, at 1:08 PM, Ben Campbell <b...@nostrum.com> wrote:
> 
>> 
>> On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF 
>> <spencerdawkins.i...@gmail.com> wrote:
>> 
>> Hi, Ben and Tommy,
>> 
>> On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell <b...@nostrum.com> wrote:
>> 
>>> On Apr 26, 2017, at 12:50 PM, Tommy Pauly <tpa...@apple.com> wrote:
>>> 
>>> Hi Ben,
>>> 
>>> Thanks for the comments! Your point about the line in Section 6 not making 
>>> sense is definitely a good point. How about this text (changes in bold):
>>> 
>>> If a TCP connection is being used to resume a previous IKE session,
>>>   the TCP Responder can recognize the session using either the IKE SPI
>>>   from an encapsulated IKE message or the ESP SPI from an encapsulated
>>>   ESP message.  If the session had been fully established previously,
>>>   it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
>>>   message if MOBIKE is supported, or an INFORMATIONAL message (a
>>>   keepalive) otherwise.  [The TCP Responder MUST NOT accept any messages
>>>   for the existing IKE session on new an incoming connection unless that 
>>> connection
>>>   begins with the stream prefix. If either the TCP Originator or TCP 
>>> Responder
>>>   cannot parse valid IKE or ESP messages on a TCP encapsulation connection
>>>   that was started with a valid stream prefix, it MUST close the TCP 
>>> connection.]
>>>   If there is instead a syntax issue within an IKE
>>>   message, an implementation MUST send the INVALID_SYNTAX notify
>>>   payload and tear down the IKE SA as usual, rather than tearing down
>>>   the TCP connection directly.
>>> 
>>> Thanks,
>>> Tommy
>> 
>> That looks good to me. I will clear, with the assumption this or similar 
>> edits will make it into the draft.
>> 
>> Does 
>> 
>> The TCP Responder MUST NOT accept any messages
>>   for the existing IKE session on new an incoming connection unless that 
>> connection
>>   begins with the stream prefix. 
>> 
>> parse for you guys? I get stuck at "on new an incoming”.
> 
> 
> I’m guessing that’s an edit-o from. Maybe it should be “on a new incoming”?

Yes, I meant "on a new incoming connection". Sorry!

Thanks,
Tommy
> 
>> 
>> Spencer
>> 
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> 
>>> 
>>>> On Apr 26, 2017, at 8:35 AM, Ben Campbell <b...@nostrum.com> wrote:
>>>> 
>>>> By the way, the DISCUSS vs COMMENT framing has gotten lost from the 
>>>> thread. Only the first point was part of the DISCUSS, the rest are 
>>>> non-binding comments. And I think the DISCUSS point is moving in the right 
>>>> direction, pending a text proposal.
>>>> 
>>>> Thanks!
>>>> 
>>>> Ben.
>>>> 
>>>>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty 
>>>>> <kathleen.moriarty.i...@gmail.com> wrote:
>>>>> 
>>>>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell <b...@nostrum.com> wrote:
>>>>>> 
>>>>>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty 
>>>>>>> <kathleen.moriarty.i...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Thanks for the quick response Paul, a few questions...
>>>>>>> 
>>>>>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters <p...@nohats.ca> wrote:
>>>>>>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
>>>>>>>> 
>>>>>>>>>> IIUC, the entire point of having the stream prefix is to allow the 
>>>>>>>>>> TCP
>>>>>>>>>> responder to demux between this protocol, and some other protocol 
>>>>>>>>>> that
>>>>>>>>>> would normally run on that port. Saying it MUST close the TCP session
>>>>>>>>>> seems to completely remove that value. I assume people meant to 
>>>>>>>>>> allow the
>>>>>>>>>> respondent to delegate a stream out to some other protocol handler 
>>>>>>>>>> if the
>>>>>>>>>> prefix is not present?
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>

Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT)

[Tommy Pauly]

Hi Ben,

Thanks for the comments! Your point about the line in Section 6 not making 
sense is definitely a good point. How about this text (changes in bold):

If a TCP connection is being used to resume a previous IKE session,
   the TCP Responder can recognize the session using either the IKE SPI
   from an encapsulated IKE message or the ESP SPI from an encapsulated
   ESP message.  If the session had been fully established previously,
   it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES
   message if MOBIKE is supported, or an INFORMATIONAL message (a
   keepalive) otherwise.  [The TCP Responder MUST NOT accept any messages
   for the existing IKE session on new an incoming connection unless that 
connection
   begins with the stream prefix. If either the TCP Originator or TCP Responder
   cannot parse valid IKE or ESP messages on a TCP encapsulation connection
   that was started with a valid stream prefix, it MUST close the TCP 
connection.]  
   If there is instead a syntax issue within an IKE
   message, an implementation MUST send the INVALID_SYNTAX notify
   payload and tear down the IKE SA as usual, rather than tearing down
   the TCP connection directly.

Thanks,
Tommy

> On Apr 26, 2017, at 8:35 AM, Ben Campbell  wrote:
> 
> By the way, the DISCUSS vs COMMENT framing has gotten lost from the thread. 
> Only the first point was part of the DISCUSS, the rest are non-binding 
> comments. And I think the DISCUSS point is moving in the right direction, 
> pending a text proposal.
> 
> Thanks!
> 
> Ben.
> 
>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty 
>>  wrote:
>> 
>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
>>> 
 On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty 
  wrote:
 
 Thanks for the quick response Paul, a few questions...
 
 On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
> 
>>> IIUC, the entire point of having the stream prefix is to allow the TCP
>>> responder to demux between this protocol, and some other protocol that
>>> would normally run on that port. Saying it MUST close the TCP session
>>> seems to completely remove that value. I assume people meant to allow 
>>> the
>>> respondent to delegate a stream out to some other protocol handler if 
>>> the
>>> prefix is not present?
>>> 
>> 
>> I believe that this is because there is presumed to be no other
>> service operating on the listening port (assuming a VPN concentrator),
>> but that's not explicitly stated either.
> 
> 
> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of
> the other kinds of SSL VPNs or as the administration interface or
> user interface.
 
 OK, sounds like I didn't help here, so the editors should propose text
 to address this gap.
>>> 
>>> I think we are on the right track here, pending proposed text.
>>> 
 
> 
>>> -- 2nd to last paragraph: "This document leaves the selection of TCP
>>> ports up to implementations."
>>> I suspect "configurable local policy" would make more sense. Leaving it
>>> up to "implementations" leaves open the chance of different
>>> implementations making non-intersecting port choices, which doesn't help
>>> interoperability.
>> 
>> 
>> This may go more into unexplained assumptions... the clients
>> authorized to connect to the server would need to know the correct
>> port to establish a session and would be given that information
>> specific to the implementation.  With this assumption, the above
>> should be fine... but editors/AD/WG, please correct me if I am wrong.
> 
> 
> I am pretty sure what is meant is "configuration" and not 
> "implementation".
 
 Is that in response to me being wrong in my assumption or the draft
 should say configuration (I think it's the latter, but important to
 check)?
>>> 
>>> We are probably splitting hairs on the meaning of “implementation” vs 
>>> “configuration”. (and maybe “deployment”). I was thinking of 
>>> “implementation” as being what developers do, and “configuring/deploying” 
>>> as what operators do. But I am aware that operators sometimes talk about 
>>> “implementing” a system.
>>> 
>>> So my point was that I assume for purposes of interoperability that a 
>>> general purpose client or server would allow the port to be changed in the 
>>> field.
>>> 
 
> 
>>> -4, first paragraph: What is the expected behavior from a peers that do
>>> not support this spec when they receive a TCP stream with the magic
>>> number on a port for some other protocol?
>> 
>> 
>> Maybe listing assumptions up front in the draft would help _IF_ the
>> assumption is that the listening server is a 

Re: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps

[Tommy Pauly]

> On Apr 25, 2017, at 2:15 PM, Joe Touch  wrote:
> 
> First, correcting the subject line (sorry - that looks like an erroneous 
> paste on my part).
> 
> Also below...
> 
> On 4/25/2017 1:59 PM, Yoav Nir wrote:
>> Hi, Joe
>> 
>> I haven’t been involved with this draft, but I don’t believe that last 
>> statement is correct:
>> 
>>> On 25 Apr 2017, at 23:03, Joe Touch > 
>>> wrote:
>>> 
 
 This issue is really everyone circling around the elephant in the room.
 Part of this draft is designed to break through firewalls and
 middle-ware that only let out port 443 traffic unmangled. We cannot
 really write
 that we are doing this, despite everyone knowing we are doing this.
 
 Your suggestions that we need to not mention 443 without updating the
 RFC defining 443 is hard to meet. Not only because we'd have an IKE
 document updating a TLS document, but also because IANA actually has
 not RFC listed for the definition of port 443.
>>> 
>>> It's not listed, but it would probably be rfc2818 or one of the ones
>>> that updates that.
>>> 
>>> However, I'd personally want someone involved from HTTPWG to sign off on
>>> this.
>>> 
 I'm already a little annoyed that the draft cannot (politically) specify
 how to use port 443 with TLS to tunnel IKE and ESP over TCP.
>>> 
>>> Here's the thing:
>>> 
>>>You get to define your service.
>>> 
>>>You do not get to define someone else's.
>>> 
>>> You would be squatting (using someone else's ports for your purposes),
>>> pure and simple.
>> 
>> I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs” in any 
>> sense of the word to the HTTP working group. 
> 
> Strictly, the port is assigned based on a service definition.
> 
> On any given host, any user can define any port any way they see fit, e.g., 
> they can run DNS on port 110 or IMAP on port 53. 
> 
> However, a new standard should never be making a change to the service 
> defined for a port that is already assigned to another party (they can change 
> a service they have been assigned).
> 
>> While it is the default port for HTTPS, that protocol can run on any port 
>> depending on the value in origin (RFC 6454).
> 
> Yes, any protocol can run on any port number (as per above), as long as the 
> endpoints agree. But that's not what you're talking about here - you're 
> saying that if you get "IKETCP" on a port, then you can trust that it is your 
> service.
> 
> That's incorrect. You don't get to define the string "IKETCP" for other 
> services. 
> 
>> The draft makes it clear in section 2 that the port used is pre-configured 
>> on both IKE initiator and IKE responder. The draft does not assign or 
>> re-assign any ports. 
> Section 4 claims that the use of the magic string differentiates this service 
> from the default assigned service or any other service. That's incorrect. You 
> don't have that authority.
> 
>> Yes, there is a suggestion to use port 443 because it is usable in more 
>> networks than other ports.
> Again, you don't have the authority to say what "IKETCP" means on port 443. 
> 
> Yes, if the port is explicitly indicated, you can use whatever port you want. 
> But you should never imply that this system should run on ports assigned to 
> other services that are running in parallel - you do not have that authority.
> 
>> That is why TCP port 443 has been used by Skype, AiCloud file sharing, Call 
>> of Duty, various “SSL VPN” products and many others. They’ve been doing that 
>> for over a decade. It is way too late to close the barn doors, and we don’t 
>> even have the authority to do so. 
> 
> You do not have the authority to endorse or standardize this behavior either.
> 
> It remains non-compliant squatting.
> 
>> We can remove all references to specific ports and leave only text about 
>> pre-configuration. IMO this amounts to a wind and a nod, because we all know 
>> which port is going to get configured.
> 
> You should be saying that the port is indicated explicitly (which is the 
> equivalent of pairwise endpoint negotiation) or use port 4500 (or maybe get 
> your own separate assignment). But the entire text on the magic number being 
> appropriate when sharing an existing assignment is incorrect and needs to be 
> removed IMO.

I suggest that we can:

- Clarify the text in section 2 (configuration) to say that the default port is 
TCP 4500, and that implementations may communicate other port options out of 
band as configuration. This is done for UDP as well. This is the "explicit" 
indication of the ports you mention above.
- Port 443 is only mentioned in the figures for the appendix. We can remove the 
mention of the port there.

As for the Stream Prefix of "IKETCP", I believe that we have good reasons to 
keep it even if we are only using the protocol on port 4500 (as would be the 
recommended/sanctioned) method. TCP port 4500 has been technically allocated to 

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Tommy Pauly]

> On Apr 25, 2017, at 5:48 AM, Mirja Kühlewind  wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-ipsecme-tcp-encaps-09: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This draft suggests that ports that are assigned to other services can
> simply be used. This is not okay. If a port is assigned to a certain
> service, this service and/or the respective RFC defines how this port is
> used. Simply changing the specified behavior by requiring a check for a
> magic number cannot be done without updating the RFC that the port
> assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
> the IANA registry would need to be updated.

At this point, the only portion of the document that mentions a port other than 
500 and 4500 is the appendix. We recommend that 4500 is used as the port for 
TCP encapsulation. The IANA registry for 4500/tcp is already assigned to IPSec 
NAT Traversal in RFC 3947; that document does not explain how TCP is to be 
used, so the reference should be updated to point to the document on TCP 
encapsulation.

We can soften the references in the appendix to the fact that other ports may, 
in fact, be used. As for the configuration, it should state 4500 as the 
default, but allow peers to configure something else out-of-band if they want 
to modify behavior (which is standard even in UDP implementations of IKE).

> 
> Further, as also mentioned in the tsv-art review (Thanks Wes!), this
> draft does not sufficiently handle the case of TCP in TCP encapsulation.
> Here a copy of the tsv-art review:
> 
> Reviewer: Wesley Eddy
> Review result: On the Right Track
> 
> This document is clear and well-written.  It can easily be implemented
> based on the description.
> 
> There are a few additional issues that should be considered with
> advice to implementers in Section 12 on performance considerations:
> 1) Invisibility of packet loss - Inner protocols that require packet
> losses as a signal of congestion (e.g. TCP) will have a challenge due
> to not being able to see any packet losses since the outer TCP will
> repair them (unless sending into a full outer TCP socket buffer shows
> up back to the inner TCP as a packet loss?).

Yes, this is definitely true. We try to capture that with the line: "This will 
make loss-
   recovery of the inner TCP traffic less reactive and more prone to
   spurious retransmission timeouts."

However, this can certainly be expanded upon.

> 2) Nesting of ECN -  Inner TCP connections will not be able to use
> effectively ECN on the portion of the path covered by the outer TCP
> connection.

Generally, IPsec tunnels will apply RFC 6040 for translating ECN markings 
between inner/outer packets. Since TCP encapsulation places the inner IP 
packets in a stream, there isn't a direct mapping.

An implementation could try to roughly map, but it may be best to suggest that 
the ECN markings for inner and outer packets be left separate. What is your 
opinion?

> 3) Impact of congestion response on aggregate - The general "TCP in
> TCP" problem is mentioned, and is mostly appropriate for a single
> flow.  If an aggregate of flows is sharing the same outer TCP
> connection, there may be additional concerns about how the congestion
> response behavior impacts an aggregate of flows, since it may cause a
> shared delay spike even to low-rate flows rather than distributing
> losses proportional to per-flow throughput.

Indeed. We can add further comments to that effect.

> 4) Additional potential for bufferbloat - Since TCP does not bound
> latency, some applications in the IPsec-protected aggregate could
> drive latency of the shared connection up and impact the aggregate of
> flows that may include real-time applications.  The socket buffer for
> the outer TCP connection might need to be limited in size to ensure
> some bounds?

We can add a comment to suggest that the buffering should be limited on the 
outer connection if possible.

> 
> Not addressing these could lead to poor experiences in deployment, if
> implementations make wrong assumptions or fail to consider them.

I do think all of these concerns go back to the overall recommendation of "use 
direct ESP or UDP Encapsulation whenever possible". Anything to help back up 
that point is great!

Thanks,
Tommy
> 
> In the security considerations section, there 

Re: [IPsec] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt

[Tommy Pauly]

I've gone through my review of the draft as well, and I think this version 
looks good!

Thanks,
Tommy

> On Apr 3, 2017, at 11:25 AM, David Schinazi  wrote:
> 
> Thanks for the update!
> 
> I've reviewed -04 and I think the draft is ready to move forward.
> 
> Regards,
> David Schinazi
> 
> 
>> On Mar 28, 2017, at 15:43, Daniel Migault > > wrote:
>> 
>> Hi, 
>> 
>> Thank you Jim for the update. Here is the version resulting from the 
>> discussion we had during the WG meeting yesterday.  Please review the 
>> document and provide your feed backs by April 4 so we can move the draft to 
>> the IESG. 
>> 
>> Yours, 
>> Daniel
>> 
>> -Original Message-
>> From: Curdle [mailto:curdle-boun...@ietf.org] On Behalf Of Jim Schaad
>> Sent: Tuesday, March 28, 2017 4:40 PM
>> To: cur...@ietf.org
>> Subject: [Curdle] FW: New Version Notification for 
>> draft-ietf-curdle-pkix-04.txt
>> 
>> Here is the promised updated draft.
>> 
>> Changes:
>> 1.  Fixed an example that David Benjamin found was wrong.  (Incorrect sign 
>> bit in public key.) 2.  Remove all of the pre-hash text except to note that 
>> it does exist.
>> 3.  No changes to the OID arc being used despite the agreement during the 
>> meeting.  After the meeting, Russ, the chairs and I had a short talk and 
>> decided that this did not need to occur.  The problem was only with getting 
>> new values assigned not with the current values which were already assigned.
>> 
>> That should be the final issues in the draft
>> 
>> Jim
>> 
>> 
>>> -Original Message-
>>> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>>> Sent: Tuesday, March 28, 2017 4:31 PM
>>> To: Jim Schaad ; Simon Josefsson 
>>> 
>>> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt
>>> 
>>> 
>>> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been 
>>> successfully submitted by Jim Schaad and posted to the IETF repository.
>>> 
>>> Name:   draft-ietf-curdle-pkix
>>> Revision:   04
>>> Title:  Algorithm Identifiers for Ed25519, Ed448, X25519 and 
>>> X448 for
>>> use in the Internet X.509 Public Key Infrastructure
>>> Document date:  2017-03-28
>>> Group:  curdle
>>> Pages:  15
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt
>>> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
>>> Htmlized:   https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
>>> Htmlized:   
>>> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04
>>> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04
>>> 
>>> Abstract:
>>>  This document specifies algorithm identifiers and ASN.1 encoding
>>>  formats for Elliptic Curve constructs using the Curve25519 and
>>>  Curve448 curves.  The signature algorithms covered are Ed25519 and
>>>  Ed448.  The key agreement algorithm covered are X25519 and X448.  The
>>>  encoding for Public Key, Private Key and EdDSA digital signature
>>>  structures is provided.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of 
>>> submission until the htmlized version and diff are available at 
>>> tools.ietf.org.
>>> 
>>> The IETF Secretariat
>> 
>> 
>> ___
>> Curdle mailing list
>> cur...@ietf.org
>> https://www.ietf.org/mailman/listinfo/curdle
>> 
>> ___
>> Curdle mailing list
>> cur...@ietf.org 
>> https://www.ietf.org/mailman/listinfo/curdle 
>> 
> 
> ___
> Curdle mailing list
> cur...@ietf.org 
> https://www.ietf.org/mailman/listinfo/curdle 
> 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Tommy Pauly]

Some servers may support that, but some may not. These sessions are often used 
for VPN access, and we've seen cases in which a particular user/certificate 
combination is only allowed to be connected once-at-a-time. That makes 
switching more complicated. Also, since the recommendation is to try sending 
the UDP first packet at least twice, the amount of time required for the user 
to wait before the fallback would kick in is only on the order of a few RTT.

I think if these session were more likely to be used for user-interactive, 
short-lived connections, I'd see more value in a nuanced racing algorithm. 
However, we often see IKE brought up in the background and stay associated for 
a very long time, making the protocol that wins the race more important, and 
the time to wait to establish slightly less important.

Thanks,
Tommy

> On Mar 19, 2017, at 11:40 AM, Eric Rescorla <e...@rtfm.com> wrote:
> 
> I haven't fully thought this through, but if yu can switch-hit between TCP
> and UDP,
> why can't you just race the setup between TCP and UDP and then if you start
> getting packets on UDP, cut over to that.
> 
> Maybe I'm just too influenced by ICE :)
> 
> -Ekr
> 
> 
> On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly <tpa...@apple.com> wrote:
> 
>> 
>> On Mar 19, 2017, at 6:47 AM, Eric Rescorla <e...@rtfm.com> wrote:
>> 
>> 
>> 
>> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <ynir.i...@gmail.com> wrote:
>> 
>>> Hi, Eric.
>>> 
>>> On 19 Mar 2017, at 4:04, Eric Rescorla <e...@rtfm.com> wrote:
>>> 
>>> [Now with the right address]
>>> 
>>> I just finished reading this document. Some comments below.
>>> 
>>> 
>>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>>>   sentinel value to indicate that a packet is IKE rather than ESP.
>>>   Given that in S 3 graf 2 you have a SHOULD-level requirement
>>>   to use typical UDP payload lengths, why not instead explicitly
>>>   limit lengths to 15 bits and use the top bit to indicate IKE versus
>>>   ESP. This would be slightly more efficient and seems simpler.
>>>   I suppose that the counterargument is that IKE over UDP behaves
>>>   differently, but in terms of implementation, that doesn't seem like
>>>  much of an argument.
>>> 
>>> 
>>> Another counter-argument is that we sometimes need the entire theoretical
>>> length of a UDP packet. The IKE_AUTH messages typically carry a certificate
>>> chain and sometimes even a CRL. And there is no way to split a certificate
>>> chain over several messages. With remote access VPN you also get a CFG
>>> payload with configuration information that can also encode an unbounded
>>> amount of data. So I would not want to constrain the certificate chains
>>> that we are able to send any more than the IP packet length already does

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

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Tommy Pauly]

> On Mar 19, 2017, at 6:47 AM, Eric Rescorla  wrote:
> 
> 
> 
> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir  > wrote:
> Hi, Eric.
> 
>> On 19 Mar 2017, at 4:04, Eric Rescorla > > wrote:
>> 
>> [Now with the right address]
>> 
>> I just finished reading this document. Some comments below.
>> 
>> 
>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>>sentinel value to indicate that a packet is IKE rather than ESP.
>>Given that in S 3 graf 2 you have a SHOULD-level requirement
>>to use typical UDP payload lengths, why not instead explicitly
>>limit lengths to 15 bits and use the top bit to indicate IKE versus
>>ESP. This would be slightly more efficient and seems simpler.
>>I suppose that the counterargument is that IKE over UDP behaves
>>differently, but in terms of implementation, that doesn't seem like
>>   much of an argument.
> 
> Another counter-argument is that we sometimes need the entire theoretical 
> length of a UDP packet. The IKE_AUTH messages typically carry a certificate 
> chain and sometimes even a CRL. And there is no way to split a certificate 
> chain over several messages. With remote access VPN you also get a CFG 
> payload with configuration information that can also encode an unbounded 
> amount of data. So I would not want to constrain the certificate chains that 
> we are able to send any more than the IP packet length already does.
> 
> OK.
> 
> 
> 
> Early on there was a proposal to increase the length field to 4 bytes to do 
> away with these IKE limitations, but that was rejected.
> 
>> - If you're going to have a framing disambiguator, why not choose
>>   one that has higher entropy. If there is a protocol with a random
>>   start, then you are going to get some collisions with 2^48 bits.
> 
> I don’t think anyone plans to implement this on any port other than 443. And 
> on that port we’re worrying about exactly one protocol and it doesn’t start 
> with “IKETCP"
> 
> Fair enough.
>  
>> - It seems like IKE associations can span TCP connections (S 6)
>>   so why not instead of doing UDP first then TCP, do happy eyeballs.
> 
> I don’t think it’s necessary to prescribe for or against this, but that is 
> what we do, and I think that is what Apple intends to do.
> 
> Right, but the text here actively discourages this.
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1 
>  
> 
> "   to reduce connection setup delays. It is recommended that theinitial 
> message over UDP is retransmitted at least once before falling back to TCP, 
> unless the Initiator knows beforehand that the   network is likely to block 
> UDP."

There's a tradeoff here between the Happy Eyeballs approach and the long-term 
benefits of choosing one option. I'm definitely a big proponent of Happy 
Eyeballs between address families, interfaces, and protocol options in general. 
However, these IKE connections will often be long-lived and tunnel a large 
amount of traffic used for many different applications. Since we view tunneling 
over UDP as so much preferable to tunneling over TCP, we want to weight the 
race more heavily in UDP's favor. The draft does not specifically say that 
attempts over UDP are ceased once the TCP attempt has begun, so there is room 
to keep 'racing' at this point. The main point we wanted to get across is that 
UDP should be given a fair shot, since it should be the preference.

Note that a Happy Eyeballs approach should always have one option be attempted 
first anyhow, since simultaneous racing just adds extra load to the network and 
servers.

Thanks,
Tommy
> 
>> " when TLS is used on the TCP connection, both the TCP Originator and TCP 
>> Responder SHOULD allow the NULL cipher to be selected for performance 
>> reasons."
>> 
>> This seems like you are going to have some problems with TLS 1.3
>> 
>> - If you are going to use TLS, shouldn't you be using ALPN?
> 
> The idea of using TLS (rather than just IKE on port 443) is to get past 
> firewalls and IDP that examine the TCP traffic to determine that it “really 
> looks like HTTPS”. There was some discussion about whether this was a good 
> idea or whether we should in such a case either give up or standardize some 
> kind of SSL-VPN. There was no consensus to go with SSL-VPN in either this 
> group or any other (there was a bar bof a few IETFs ago)
> 
> OK. You're still going to have a problem with 1.3...
> 
> -Ekr
> ___
> 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] AD review of draft-ietf-ipsecme-tcp-encaps

[Tommy Pauly]

Hi Kathleen,

I've just posted a new version to fix some minor nits and add a reference for 
the SHA-1 digest used for NAT detection:
https://www.ietf.org/id/draft-ietf-ipsecme-tcp-encaps-09.txt

>From my perspective, I think starting a IETF last call now make sense.

Thanks!
Tommy

> On Mar 9, 2017, at 10:48 AM, Kathleen Moriarty 
> <kathleen.moriarty.i...@gmail.com> wrote:
> 
> On Thu, Mar 9, 2017 at 12:47 PM, Tommy Pauly <tpa...@apple.com 
> <mailto:tpa...@apple.com>> wrote:
>> Hi Kathleen,
>> 
>> Yes, this is referring to how the existing NAT detection works in IKEv2:
>> 
>> https://tools.ietf.org/html/rfc7296 <https://tools.ietf.org/html/rfc7296>
>> 
>> Section 2.23. NAT Traversal
>> 
>>   o  The data associated with the NAT_DETECTION_SOURCE_IP notification
>>  is a SHA-1 digest of the SPIs (in the order they appear in the
>>  header), IP address, and port from which this packet was sent.
>> 
>> We can add a pointer to the section of the RFC.
> 
> Great.  Please let me know when that is done and I can start IETF last
> call.  Does the WG want me to start that right away or to wait until
> after Chicago?  I'm inclined to start it right away and have it on the
> first telechat after.
> 
> Thanks,
> Kathleen
> 
>> 
>> Thanks,
>> Tommy
>> 
>>> On Mar 9, 2017, at 9:39 AM, Kathleen Moriarty 
>>> <kathleen.moriarty.i...@gmail.com> wrote:
>>> 
>>> Hello,
>>> 
>>> Thank you for your work on draft-ietf-ipsecme-tcp-encaps.  It's a well
>>> written draft and I just have one question.
>>> 
>>> Section 7: Why is SHA-1 used?  If this is a result of the protocol and
>>> prior RFCs, please include a reference. And an explanation on list
>>> would be helpful (pointer is fine if this was already discussed.
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Best regards,
>>> Kathleen
>>> 
>>> ___
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen

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

Re: [IPsec] AD review of draft-ietf-ipsecme-tcp-encaps

[Tommy Pauly]

Hi Kathleen,

Yes, this is referring to how the existing NAT detection works in IKEv2:

https://tools.ietf.org/html/rfc7296

Section 2.23. NAT Traversal

   o  The data associated with the NAT_DETECTION_SOURCE_IP notification
  is a SHA-1 digest of the SPIs (in the order they appear in the
  header), IP address, and port from which this packet was sent.

We can add a pointer to the section of the RFC.

Thanks,
Tommy

> On Mar 9, 2017, at 9:39 AM, Kathleen Moriarty 
>  wrote:
> 
> Hello,
> 
> Thank you for your work on draft-ietf-ipsecme-tcp-encaps.  It's a well
> written draft and I just have one question.
> 
> Section 7: Why is SHA-1 used?  If this is a result of the protocol and
> prior RFCs, please include a reference. And an explanation on list
> would be helpful (pointer is fine if this was already discussed.
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
> 
> ___
> 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] Review of draft-ietf-ipsecme-tcp-encaps-05

[Tommy Pauly]

Hello,

I've posted a new draft with a fix for the TCP Originator vs Original Initiator 
explanation, and a couple typos.

https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-07

I believe this addresses all outstanding comments!

Thanks,
Tommy

> On Feb 7, 2017, at 9:44 AM, Tommy Pauly <tpa...@apple.com> wrote:
> 
> Hi Valery,
> 
> Thanks for the feedback! I'll clarify that the TCP Originator is the same as 
> the original initiator of the first IKE SA, as well as fixing the 
> typographical errors.
> 
> If anyone else has more feedback, please chime in! I'll wait a day or so 
> before updating the draft, to batch any other changes that should be made.
> 
> Thanks,
> Tommy
> 
>> On Feb 7, 2017, at 5:54 AM, Valery Smyslov <sva...@gmail.com> wrote:
>> 
>> Hi Tommy,
>> 
>> thank you for the quick update. A couple nits:
>> 
>> 1. Section 1.2:
>> s/the the/the
>> 
>> 2. Section 1.2:
>>  The TCP  
>>  Originator MUST be the same as the "Original Initiator", or the  
>>  Initiator of the first IKE SA exchange for a given IKE session.
>> 
>> Again, this is confusing. In RFC7296 the term " Original Initiator" is 
>> defined as:
>>   The "original initiator
>>always refers to the party who initiated the exchange that resulted
>>in the current IKE SA.  In other words, if the "original responder"
>>starts rekeying the IKE SA, that party becomes the "original
>>initiator" of the new IKE SA."
>> 
>> "the Initiator of the first IKE SA exchange for a given IKE session" is also
>> wrong, since IKE session means IKE SA and it can be a rekey of previous
>> IKE SA when entities swap their original roles.
>> 
>> This is now what we want it to mean, so an additional clarification is 
>> needed.
>> Something along the lines:
>> 
>>   The TCP Originator MUST be the same as the entity who originally
>>   initiated the first IKE SA (in a series of possibly several rekeyed
>>   IKE SAs).
>> 
>> Otherwise it looks good.
>> 
>> Regards,
>> Valery.
>> 
>>> Hi Valery,
>>> 
>>> Thanks so much for your comments! I have posted a new version of the draft 
>>> here:
>>> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06
>>> 
>>> Responses inline.
>>> 
>>> Best,
>>> Tommy
>>> 
>>>> On Feb 2, 2017, at 4:13 AM, Valery Smyslov <sva...@gmail.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> here is my review of draft-ietf-ipsecme-tcp-encaps-05.
>>>> The draft is in a good shape, but a bit of final polishing is required.
>>>> 
>>>> 1. The terms "tunnel", "tunneled" are used throughout the document
>>>>  when referring to ESP SA. I think it is technically incorrect, since
>>>>  ESP supports both tunnel and transport modes, so the document
>>>>  should use more appropriate terms like "IPsec SA", "ESP packets" etc.
>>> 
>>> Great point. I have removed the references to tunnel, and replaced with SA, 
>>> generally.
>>> 
>>>> 
>>>> 2. Section 4.
>>>>  This value is
>>>> only sent once, by the Initiator only, at the beginning of any stream
>>>> of IKE and ESP messages.
>>>> 
>>>> If other framing protocols are used within TCP to further encapsulate
>>>> or encrypt the stream of IKE and ESP messages, the Stream Prefix must
>>>> be at the start of the Initiator's IKE and ESP message stream within
>>>> the added protocol layer [Appendix A].
>>>> 
>>>> Using "Initiator" is wrong here, since the TCP stream may be re-established
>>>> after the peers rekeyed IKE SA and changed their roles (so that original
>>>> Initiator becomes Responder). It either must be "original Initiator"
>>>> (with all explanations who it is, as in Section 6) or, preferably,
>>>> "originator of TCP stream" (or smth like that).
>>>> 
>>>> Actually, "Initiator" is used in a lot of places throughout the document
>>>> and in most cases it means "original Initiator of the first IKE SA in a 
>>>> series
>>>> of possible successive rekeys of this SA". It is good to look through
>>>> all these uses and either clarify this term in all places it is used, or 
>>>> add
>>>> some pa

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

[Tommy Pauly]

Thanks for sending out the corrected draft name, Tero. I think this draft is in 
good shape in general and we should move forward with it.

The only thing that seems to need ironing out is the specific IANA hash value. 
I can see the argument either way: as the draft points out, 0 makes sense for 
the Identity hash, since it can be viewed as "no hash at all". However, I agree 
with your point that 0 may often be used in code to indicate an uninitialized 
value. I would be concerned if existing implementations flagged 0 as an error, 
here, as well.

I think it would make sense to do a quick poll of the WG to get some consensus 
on this. At this point, I'm mildly in favor of a new value (5).

Thanks,
Tommy

> On Feb 9, 2017, at 4:40 AM, Tero Kivinen  wrote:
> 
> Ah I noticed that my last call email had wrong draft name in the
> subject line and in the link. The correct draft name is of course
> draft-ietf-ipsecme-eddsa-00 not *-nir-* version.
> 
> David Schinazi writes:
>> I've reviewed this draft. I support it and believe it is ready to move 
>> forward
>> towards becoming a standards-track RFC. Also, would it make sense to ask
>> IANA for early assignment of the code point? Using 0 sounds reasonable to me.
> 
> As this is expert review registry there is no need to ask for early
> allocation, the normal process is just to fill in the IANA general
> request for assignments, which then goes to the IANA and they will
> then send it to the expert (me) for verification.
> 
> If normal number (other than 0) would be given out, then I would just
> say yes, but allocating 0, which in registry is marked as:
> 
>   0   Reserved[RFC7427]
> 
> and is not part of the :
> 
>   5-1023  Unassigned
> 
> range, then I would be bit more hesitant to give it out, and would
> most likely want to poll the WG and list before making decision.
> 
> I actually myself think it would be better to just allocate next free
> number from the unassigned space, and keep the value 0 as reserved...
> 
> For example we do not use value 0 of Encryption Algorithms transform
> to mean ENCR_NULL, we do have separate number allocated for it. On the
> other hand we do have value 0 meaning NONE in the Integrity algorithm
> transform ID table and for diffie hellman values, but there the
> meaning is bit different, it means there is no value for that id, here
> it would be meaning that there is this identity function version of
> the hash function. 
> 
> As an expert and as a implementor I think I would prefer next free
> number over 0... Quite commonly in the code we use value 0 as meaning,
> we have not yet received anything, or we have not yet initialized this
> field, and having separate value for identity function might make
> things easier. But if others have good reasons why the value 0 is
> better, feel free to tell me...
> -- 
> 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] Review of draft-ietf-ipsecme-tcp-encaps-05

[Tommy Pauly]

Hi Valery,

Thanks for the feedback! I'll clarify that the TCP Originator is the same as 
the original initiator of the first IKE SA, as well as fixing the typographical 
errors.

If anyone else has more feedback, please chime in! I'll wait a day or so before 
updating the draft, to batch any other changes that should be made.

Thanks,
Tommy

> On Feb 7, 2017, at 5:54 AM, Valery Smyslov  wrote:
> 
> Hi Tommy,
> 
> thank you for the quick update. A couple nits:
> 
> 1. Section 1.2:
> s/the the/the
> 
> 2. Section 1.2:
>   The TCP  
>   Originator MUST be the same as the "Original Initiator", or the  
>   Initiator of the first IKE SA exchange for a given IKE session.
> 
> Again, this is confusing. In RFC7296 the term " Original Initiator" is 
> defined as:
>The "original initiator
> always refers to the party who initiated the exchange that resulted
> in the current IKE SA.  In other words, if the "original responder"
> starts rekeying the IKE SA, that party becomes the "original
> initiator" of the new IKE SA."
> 
> "the Initiator of the first IKE SA exchange for a given IKE session" is also
> wrong, since IKE session means IKE SA and it can be a rekey of previous
> IKE SA when entities swap their original roles.
> 
> This is now what we want it to mean, so an additional clarification is needed.
> Something along the lines:
> 
>The TCP Originator MUST be the same as the entity who originally
>initiated the first IKE SA (in a series of possibly several rekeyed
>IKE SAs).
> 
> Otherwise it looks good.
> 
> Regards,
> Valery.
> 
>> Hi Valery,
>> 
>> Thanks so much for your comments! I have posted a new version of the draft 
>> here:
>> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06
>> 
>> Responses inline.
>> 
>> Best,
>> Tommy
>> 
>>> On Feb 2, 2017, at 4:13 AM, Valery Smyslov  wrote:
>>> 
>>> Hi,
>>> 
>>> here is my review of draft-ietf-ipsecme-tcp-encaps-05.
>>> The draft is in a good shape, but a bit of final polishing is required.
>>> 
>>> 1. The terms "tunnel", "tunneled" are used throughout the document
>>>   when referring to ESP SA. I think it is technically incorrect, since
>>>   ESP supports both tunnel and transport modes, so the document
>>>   should use more appropriate terms like "IPsec SA", "ESP packets" etc.
>> 
>> Great point. I have removed the references to tunnel, and replaced with SA, 
>> generally.
>> 
>>> 
>>> 2. Section 4.
>>>   This value is
>>>  only sent once, by the Initiator only, at the beginning of any stream
>>>  of IKE and ESP messages.
>>> 
>>>  If other framing protocols are used within TCP to further encapsulate
>>>  or encrypt the stream of IKE and ESP messages, the Stream Prefix must
>>>  be at the start of the Initiator's IKE and ESP message stream within
>>>  the added protocol layer [Appendix A].
>>> 
>>> Using "Initiator" is wrong here, since the TCP stream may be re-established
>>> after the peers rekeyed IKE SA and changed their roles (so that original
>>> Initiator becomes Responder). It either must be "original Initiator"
>>> (with all explanations who it is, as in Section 6) or, preferably,
>>> "originator of TCP stream" (or smth like that).
>>> 
>>> Actually, "Initiator" is used in a lot of places throughout the document
>>> and in most cases it means "original Initiator of the first IKE SA in a 
>>> series
>>> of possible successive rekeys of this SA". It is good to look through
>>> all these uses and either clarify this term in all places it is used, or add
>>> some para in the beginning of the draft, e.g. like it is done in RFC4555:
>>> 
>>>  In this document, the term "initiator" means the party who originally
>>>  initiated the first IKE_SA (in a series of possibly several rekeyed
>>>  IKE_SAs); "responder" is the other peer.  During the lifetime of the
>>>  IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA
>>>  exchanges; in this case, the terms "exchange initiator" and "exchange
>>>  responder" are used.  The term "original initiator" (which in [IKEv2]
>>>  refers to the party who started the latest IKE_SA rekeying) is not
>>>  used in this document.
>>> 
>>> I also noticed that both "Initiator" and "initiator" are used in the 
>>> document
>>> (as well as "Responder" and "responder"). It's better to use one form
>>> (preferably with capital letter, like in RFC7296). RFC Editor will change
>>> them to one form in any case, so you can ease her work a bit.
>> 
>> I've switched to use the capitalized version of Initiator and Responder.
>> 
>>> 
>>> I'd also suggest to introduce some term for the party, that creates
>>> TCP session (e.g. "TCP originator") and use it where appropriate,
>>> so that IKE roles are clearly distinct from TCP roles. In this case
>>> you can get rid of "Initiator" in most places replacing it with "TCP 
>>> originator".
>> 
>> I added the terms "TCP Originator" and "TCP Responder" in the terminology 
>> section, with an
> 

Re: [IPsec] Review of draft-ietf-ipsecme-tcp-encaps-05

[Tommy Pauly]

Hi Valery,

Thanks so much for your comments! I have posted a new version of the draft here:
https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-06

Responses inline.

Best,
Tommy

> On Feb 2, 2017, at 4:13 AM, Valery Smyslov  wrote:
> 
> Hi,
> 
> here is my review of draft-ietf-ipsecme-tcp-encaps-05.
> The draft is in a good shape, but a bit of final polishing is required.
> 
> 1. The terms "tunnel", "tunneled" are used throughout the document
>when referring to ESP SA. I think it is technically incorrect, since 
>ESP supports both tunnel and transport modes, so the document
>should use more appropriate terms like "IPsec SA", "ESP packets" etc.

Great point. I have removed the references to tunnel, and replaced with SA, 
generally.

> 
> 2. Section 4.
>This value is
>   only sent once, by the Initiator only, at the beginning of any stream
>   of IKE and ESP messages.
> 
>   If other framing protocols are used within TCP to further encapsulate
>   or encrypt the stream of IKE and ESP messages, the Stream Prefix must
>   be at the start of the Initiator's IKE and ESP message stream within
>   the added protocol layer [Appendix A].
> 
> Using "Initiator" is wrong here, since the TCP stream may be re-established
> after the peers rekeyed IKE SA and changed their roles (so that original
> Initiator becomes Responder). It either must be "original Initiator" 
> (with all explanations who it is, as in Section 6) or, preferably, 
> "originator of TCP stream" (or smth like that).
> 
> Actually, "Initiator" is used in a lot of places throughout the document 
> and in most cases it means "original Initiator of the first IKE SA in a series
> of possible successive rekeys of this SA". It is good to look through 
> all these uses and either clarify this term in all places it is used, or add 
> some para in the beginning of the draft, e.g. like it is done in RFC4555:
> 
>   In this document, the term "initiator" means the party who originally
>   initiated the first IKE_SA (in a series of possibly several rekeyed
>   IKE_SAs); "responder" is the other peer.  During the lifetime of the
>   IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA
>   exchanges; in this case, the terms "exchange initiator" and "exchange
>   responder" are used.  The term "original initiator" (which in [IKEv2]
>   refers to the party who started the latest IKE_SA rekeying) is not
>   used in this document.
> 
> I also noticed that both "Initiator" and "initiator" are used in the document
> (as well as "Responder" and "responder"). It's better to use one form
> (preferably with capital letter, like in RFC7296). RFC Editor will change 
> them to one form in any case, so you can ease her work a bit.

I've switched to use the capitalized version of Initiator and Responder.

> 
> I'd also suggest to introduce some term for the party, that creates 
> TCP session (e.g. "TCP originator") and use it where appropriate,
> so that IKE roles are clearly distinct from TCP roles. In this case
> you can get rid of "Initiator" in most places replacing it with "TCP 
> originator".

I added the terms "TCP Originator" and "TCP Responder" in the terminology 
section, with an explanation of this distinction. I've used the new terms where 
appropriate throughout the document.

> 
> 3. Section 6.
>   When the IKE initiator uses TCP encapsulation for its negotiation,...
> 
> "its negotiation" is confusing here, since TCP encapsulation is not 
> negotiated.
> I suggest removing "for its negotiation" completely (or change to "for IKE SA 
> negotiation").

Removed the phrase.

> 
> 4. Section 6.
>   Once all
>   SAs have been deleted,...
> 
> "all SAs" is confusing. Later in this section it is stated that multiple IKE 
> SAs
> MUST NOT share a single TCP connection. Is this a leftover from an early 
> design?

Switched to "Once the SA has been..."

> 
> 5. Section 6.
>   If the connection is being used to resume a previous IKE session...
> 
> For clarity:  s/connection/TCP connection

Switched to "if a TCP connection".

> 
> 6. Section 6.
>   A responder SHOULD at any given time send packets for an IKE SA and
>   its Child SAs over only one TCP connection.
> 
> Why only Responder? What about Initiator? I think this requirement
> is valid for both.

Slightly modified the phrasing. The paragraph above describes the 
Initiator/Originator behavior.

> 
> 7. Section 6.
>   In order to be considered valid for choosing a TCP
>   connection, an IKE message successfully decrypt and be authenticated,
>   not be a retransmission of a previously received message, and be
>   within the expected window for IKE message IDs.  Similarly, an ESP
>   message must pass authentication checks and be decrypted, not be a
>   replay of a previous message.
> 
> "an IKE message successfully decrypt" - is it OK with the grammar?
> Shouldn't it be: "an IKE message must be successfully decrypted"?

Thanks for catching! Fixed.

> 
> What about ES, I 

[IPsec] New version: draft-ietf-ipsecme-tcp-encaps-05

[Tommy Pauly]

Hello,

I've uploaded a new version of the TCP Encapsulation draft that is in WG last 
call, incorporating the feedback from Tero and Valery.

Please take another read through, and let me know your feedback and if you 
think we want any more changes to the document.

Thanks!
Tommy

> On Jan 23, 2017, at 1:59 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions of 
> the IETF.
> 
>Title   : TCP Encapsulation of IKE and IPsec Packets
>    Authors : Tommy Pauly
>  Samy Touati
>  Ravi Mantha
>   Filename: draft-ietf-ipsecme-tcp-encaps-05.txt
>   Pages   : 21
>   Date: 2017-01-23
> 
> Abstract:
>   This document describes a method to transport IKE and IPsec packets
>   over a TCP connection for traversing network middleboxes that may
>   block IKE negotiation over UDP.  This method, referred to as TCP
>   encapsulation, involves sending both IKE packets for tunnel
>   establishment as well as tunneled packets using ESP over a TCP
>   connection.  This method is intended to be used as a fallback option
>   when IKE cannot be negotiated over UDP.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-05
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] Review of the draft-ietf-ipsecme-tcp-encaps-04

[Tommy Pauly]

> On Jan 19, 2017, at 11:47 PM, Valery Smyslov  wrote:
> 
> HI Tero,
> 
>> Actually Valery did raise good point, that for IKE this might cause
>> issues.
>> 
>> Now when I am thinking about this, I think that for IKE packets the
>> response to the IKE request should go to the same TCP session where
>> the request came in. This would be aligned with the RFC7296 which says
>> you reverse ip-addresses and ports for incoming IKE request, and reply
>> to that address.
> 
> That makes sense.
> 
>> For new requests the IKE should use the same TCP session than what is
>> being used for ESP, i.e., the most fresh one.
>> 
>> The most fresh should then be defined as the one which has received
>> ESP sequence number which is not out of order (note, that there might
>> be multipe ESP SAs in the same TCP connection, so largest sequence
>> number is not right way to express this), or which has received new
>> IKE request (note, not IKE respose, or retrasmitted request) last.
> 
> It doesn't really help to prevent attack, but unnecessary complicates 
> implementations.
> I'd rather suggest to choose the TCP connection over which the latest
> valid ESP or IKE packet (that is not a retransmission) is received. 

Right, so how about we say that a packet that causes the responder to choose 
which TCP connection to use must be:
- A valid IKE or ESP message that can be successfully decrypted and 
authenticated
- Not a retransmission
- Not outside of the ESP replay window
- In order for the sequence of message IDs for that SA

Does that work to sufficiently be conservative about which packets to trust, 
while not adding undue complication?

Thanks,
Tommy

> 
> In most cases this is equivalent to the rules you suggests
> (since TCP prevents reordering the latest packet will have
> the highest SN/MID). In case of powerful attacker on the path,
> who can steal, drop, modify and replay packets, the rules
> you suggest won't help anyway.
> 
> Regards,
> Valery.
> 

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

Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04

[Tommy Pauly]

Hi Tero,

Thanks for the comments! Responses inline.

Best,
Tommy

> On Jan 11, 2017, at 7:04 AM, Tero Kivinen  wrote:
> 
> This draft should be quite ready for the WGLC, so I will start that
> shortly, but here are comments from my chair review of the draft.
> 
> Consider these comments just like any WGLC comments.
> 
> --
> 
> In section 6, there is text saying:
> 
>   In order to close an IKE session, either the initiator or responder
>   SHOULD gracefully tear down IKE SAs with DELETE payloads.  Once all
>   SAs have been deleted, the initiator of the original connection MUST
>   close the TCP connection.
> 
> I do not understand the reasoning behind the MUST, or actually also
> whether it is that it MUST be initiator of the original connection
> closing, it or that connection MUST be closed after all SAs are
> deleted.
> 
> If it is supposed to say that once all SAs are deleted the connection
> MUST be deleted, then it does not really matter who will close it, as
> once all SAs are gone, there cannot be any new IKE exchanges on the
> TCP connection.
> 
> If it is trying to say that only original initiator can close the
> connection, just in case it wants to reuse it for new IKE INIT
> message, then the text needs to change to say that.
> 
> I.e., what is this MUST trying to say?

This MUST should probably be downgraded to a SHOULD, and add explanation about 
the reuse case. The point of this text was to make sure that initiators don’t 
needlessly leave TCP connections open to responders, and take up resources on 
the responder. A better text would be:

"In order to close an IKE session, either the initiator or responder
  SHOULD gracefully tear down IKE SAs with DELETE payloads.  Once all
  SAs have been deleted, the initiator of the original connection SHOULD
  close the TCP connection if it does not intend to use the connection for
  another IKE session to the responder. If the connection is left idle,
  and the responder needs to clean up resources, the responder MAY
  close the TCP connection."
> 
> --
> 
> 
>   The streams of data sent over any TCP connection used for this
>   protocol MUST begin with the stream prefix value followed by a
>   complete message, which is either an encapsulated IKE or ESP message.
> ...
> 
> I think this should be rephrased in a way that when initiator creates
> new TCP connection, it MUST send the stream prefix value first,
> followed by a IKE or ESP message.
> 
> The responder might receive them in pieces, because of the TCP, so
> responder should not consider it an error to only receive stream
> prefix and parts of the first message. If it sees partial message it
> should wait for the rest of the message to come or untile timeout
> occurs. Note, the responder do need timeout in this case, as we do
> want to clean up the state if we have partial messages in the TCP
> stream, even when the TCP connection itself is not broken.

Good point, I will clarify the text to make it clearer that the prefix value 
must be sent first on any new connection, and that the responder has to deal 
with parsing partial messages.
> 
> --
> 
>   If the connection is being used to resume a previous IKE session, the
>   responder can recognize the session using either the IKE SPI from an
>   encapsulated IKE message or the ESP SPI from an encapsulated ESP
>   message.
> 
> There should be note here and later explaining that this IKE or ESP
> message must pass authentication checks, and MUST be fresh. I.e.,
> replaying old IKE or ESP message over tcp stream must not move traffic
> to new TCP connection. This text here tells which IKE it belongs, but
> later three is text saying:
> 
>   It should choose the TCP
>   connection on which it last received a valid and decryptable IKE or
>   ESP message.
> 
> so that should also include note, that messages must be fresh. Note,
> that definition of fresh is not obvious. For the ESP it is not enough
> that it is unseen message in the replay window, as the replay window
> might be quite large, and acquiring ESP message not seen by the other
> end is quite possible. I think it is best to require that the ESP
> message must be with higher sequence number ever seen before... This
> should be happening anyways, as there will not be reordering happening
> inside the TCP connection, so this will not cause issues for normal
> cases.
> 
> Same for the IKE SA, i.e. the message-id must be larger than anything
> seen before, not just something that is in the window.

I will add text to specify that the IKE and ESP messages must be valid (pass 
authentication and decryption), and have higher IDs than previous messages.
> 
> Also why this text has only lowercase "should", not uppercase MUST? 

I may want to upgrade it to a SHOULD. If we are in a state in which there are, 
for a time, two TCP connections up, the only reliable way to return a message 
from the responder to the initiator is to use the most 

Re: [IPsec] New Version of Split DNS for IKEv2

[Tommy Pauly]

Hi Daniel,

Thanks for the review comments! Responses inline.

Tommy

> On Dec 13, 2016, at 10:46 AM, Daniel Migault <daniel.miga...@ericsson.com> 
> wrote:
> 
> Hi, 
> 
> Please find my comments on draft-pauly-ipsecme-split-dns-02. 
> 
> Yours, 
> Daniel
> 
> 
> 3.  Protocol Exchange
> 
> 3.1.  Configuration Request
> 
>An initiator MAY convey its current DNSSEC trust anchors for the
>domain specified in the INTERNAL_DNS_DOMAIN attribute.  If it does
>not wish to convey this information, it MUST use a length of 0.
> 
> MGLT: I think a high level explanation may be needed for the reader to 
> understand why the initiator provides the trust anchor but maybe that is the 
> responder and not the initiator.
> 
Sure, we can add more discussion around this to explain it.

>
> 3.2.  Configuration Reply
> 
>For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute,
>one or more INTERNAL_DNSSEC_TA attributes MAY be included by the
>responder.  This attribute lists the corresponding DSSNEC
> 
> MGLT: DNSSEC

=) Good catch!

> 
>trust
>anchor in the DNS wire format of a DS record as specified in
>[RFC4034].
> 
> MGLT: I think that is te first time in the draft that mentions the TA is in 
> fact the hash of it. That is fine, but maybe that could be mentioned earlier 
> in the introduction for example. In case that storing TA as DS is defined 
> somewhere a reference to that document might be useful. Otherwise, maybe we 
> should mention that is a common practice. What I would like to point is that 
> we may have to re-read the draft with that in mind.  
> 

Okay, we can also add more discussion around this in the next update.

>  
> 3.4.  Example Exchanges
> 
> 3.4.2.  Requesting Limited Domains
> 
>In this example exchange, the initiator requests INTERNAL_IP4_DNS and
>INTERNAL_DNS_DOMAIN attributes in its CFG_REQUEST, specifically
>requesting only "example.com <http://example.com/>" and "other.com 
> <http://other.com/>".  The responder replies
>with two DNS server addresses, 198.51.100.2 and 198.51.100.4, and two
>domains, "example.com <http://example.com/>" and "city.other.com 
> <http://city.other.com/>".  Note that one of the
>domains in the CFG_REPLY, "city.other.com <http://city.other.com/>", is a 
> subset of the
>requested domain, "other.com <http://other.com/>".  This indicates that 
> hosts within
>"other.com <http://other.com/>" that are not within "city.other.com 
> <http://city.other.com/>" should be resolved
>using an external DNS server.
> 
> MGLT: I migth be wrong but can *.other.com <http://other.com/> stands for 
> example.other.com <http://example.other.com/> as well as 
> example.city.other.com <http://example.city.other.com/>. If so how wildcard 
> is handled. Maybe the wildcard use case should be explained.  
>

We have some text in section 5 around how the segments in the domain are 
complete segments. This covers part of the behavior.

For example, if the
   INTERNAL_DNS_DOMAIN attribute specifies "example.com", then
   "example.com", "www.example.com" and "mail.eng.example.com" MUST be
   resolved using the internal DNS resolver(s), but "anotherexample.com"
   and "ample.com" MUST be resolved using the system's external DNS
   resolver(s).

I don't want people to be using an actual * wildcard in the protocol, though. 
I'll probably add a mention in the text that * does not imply a wildcard and 
should not be used.

> 
> 5.  Split DNS Usage Guidelines
> 
> An initiator SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing
>domains that are designated Special Use Domain Names in [RFC6761],
>such as "local", "localhost", "invalid", etc.  Although it may
>explicitly wish to support some Special Use Domain Names.
> 
>  MGLT: It sounds to me that deciding how to handle the .local is part of the 
> initiator policy. I would propose something around. 
>  
>  Handling domains that are designated Special Use Domain Names in [RFC6761], 
> such as "local", "localhost", "invalid", etc. with the INTERNAL_DNS_DOMAIN is 
> part of the initiator's policy. Unless the initiator explicitly wish to 
> support some Special Use Domain Names, it SHOULD ignore INTERNAL_DNS_DOMAIN 
> attributes containing Special Use Domain Names. 

That's a better wording, yes. Will change.

>
>  I think there is a "dommain" somewhere in the text 

Quite right. Again, thanks for catching!

Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

[Tommy Pauly]

The VPN client can do the synthesis themselves using RFC 6052 
(https://tools.ietf.org/html/rfc6052) and RFC 7050 
(https://tools.ietf.org/html/rfc7050), querying ipv4only.arpa over the DNS.

macOS and iOS also support synthesis in the OS by calling getaddrinfo() with 
the IPv4 address as a string, and returning an IPv6 sockaddr when on a NAT64 
network.

Thanks,
Tommy

> On Dec 9, 2016, at 2:06 PM, Heatley, Nick <nick.heat...@ee.co.uk> wrote:
> 
> Thanks for this, very useful.
> Is the vpn client also discovering the well known prefix for v6 address 
> synthesis itself, or relying on the OS to provide that?
> 
> 
> 
>  Original message 
> From: Tommy Pauly <tpa...@apple.com <mailto:tpa...@apple.com>> 
> Date: 09/12/2016 17:32 (GMT+00:00)
> To: "Heatley, Nick" <nick.heat...@ee.co.uk <mailto:nick.heat...@ee.co.uk>> 
> Cc: "Bjoern A. Zeeb" <bzeeb-li...@lists.zabbadoz.net 
> <mailto:bzeeb-li...@lists.zabbadoz.net>>, Bill Fenner <fen...@fenron.com 
> <mailto:fen...@fenron.com>>, ipsec@ietf.org <mailto:ipsec@ietf.org>, 
> suns...@ietf.org <mailto:suns...@ietf.org>
> Subject: Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients
> 
> With our push to support NAT64 networks (without 464xlat) for Apple's 
> devices, we added support for NAT64 networks to both our IKEv1 and IKEv2 
> clients a few releases ago. It was a fairly straightforward change. The main 
> parts are making sure any IPv4 literals meant to be use outside the tunnel 
> that come across in the IKE exchange are synthesized into IPv6 addresses; and 
> making sure that the ESP layer is happy encapsulating IPv4 in IPv6 for 
> tunnels. Historically, many implementations only supported IPv4-in-IPv4, 
> IPv6-in-IPv6, and IPv6-in-IPv4.
> 
> >From an interop perspective, this is just a change that needs to be made on 
> >the client behind the NAT64, and requires no protocol changes in IKE or 
> >knowledge on the server side.
> 
> Thanks,
> Tommy Pauly
> 
> > On Dec 9, 2016, at 9:03 AM, Heatley, Nick <nick.heat...@ee.co.uk 
> > <mailto:nick.heat...@ee.co.uk>> wrote:
> > 
> > It is just the single NAT64 that is in question (I also tend to think that 
> > is broken for IPsec clients?).
> > 
> > Popular IPsec clients work perfectly via 464xlat (double NAT64).
> > 
> > 
> > 
> > -Original Message-
> > From: sunset4 [mailto:sunset4-boun...@ietf.org 
> > <mailto:sunset4-boun...@ietf.org>] On Behalf Of Bjoern A. Zeeb
> > Sent: 09 December 2016 16:33
> > To: Bill Fenner
> > Cc: ipsec@ietf.org <mailto:ipsec@ietf.org>; suns...@ietf.org 
> > <mailto:suns...@ietf.org>
> > Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients
> > 
> > On 9 Dec 2016, at 16:07, Bill Fenner wrote:
> > 
> >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <nick.heat...@ee.co.uk 
> >> <mailto:nick.heat...@ee.co.uk>>
> >> wrote:
> >> 
> >>> Hi All,
> >>> 
> >>> The sunset4 minutes suggest NAT64 SSID to become the default?
> >>> 
> >>> Just checking, is there any summary on how VPN clients behaved on the
> >>> nat64 SSID following the event?
> >>> 
> >> 
> >> Just an anecdote, not actual information: I have two different ways to 
> >> contact my office VPN server (SSL VPN and IPSEC); neither one worked 
> >> from NAT64.  The vendor documentation says that they don't support 
> >> IPv6 transport for the SSL VPN; I do not know what went wrong with the 
> >> IPSEC VPN.  The vendor introduced support for IPSEC with v6 transport 
> >> in their newest software, to which we'll upgrade soon; perhaps that 
> >> upgrade will include whatever is required for it to work through NAT64 
> >> too.  Their support matrix still says that even the newest software 
> >> does not support SSL VPN over IPv6.
> > 
> > That’s maybe for the ipsec wg but while native IPv6 VPN has been working 
> > fine for me for ages, how would a NAT64 policy exchange actually look like 
> > (I am thinking about what is done for IPv4 NAT or double NAT within the 
> > same address family);  I doubt that different AFs on each end as part of 
> > the policy are specified to work, so I’d not expect IPsec VPNs to work 
> > across a NAT64 (from a v6 to a v4 endpoint);  someone surprise me and say 
> > with IKEv2 you can?  Someone surprise me and say with a double NAT64 it can 
> > work?
> > 
> > /bz
> > 
> > ___
> > sunset4

Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

[Tommy Pauly]

With our push to support NAT64 networks (without 464xlat) for Apple's devices, 
we added support for NAT64 networks to both our IKEv1 and IKEv2 clients a few 
releases ago. It was a fairly straightforward change. The main parts are making 
sure any IPv4 literals meant to be use outside the tunnel that come across in 
the IKE exchange are synthesized into IPv6 addresses; and making sure that the 
ESP layer is happy encapsulating IPv4 in IPv6 for tunnels. Historically, many 
implementations only supported IPv4-in-IPv4, IPv6-in-IPv6, and IPv6-in-IPv4.

From an interop perspective, this is just a change that needs to be made on the 
client behind the NAT64, and requires no protocol changes in IKE or knowledge 
on the server side.

Thanks,
Tommy Pauly

> On Dec 9, 2016, at 9:03 AM, Heatley, Nick <nick.heat...@ee.co.uk> wrote:
> 
> It is just the single NAT64 that is in question (I also tend to think that is 
> broken for IPsec clients?).
> 
> Popular IPsec clients work perfectly via 464xlat (double NAT64).
> 
> 
> 
> -Original Message-
> From: sunset4 [mailto:sunset4-boun...@ietf.org] On Behalf Of Bjoern A. Zeeb
> Sent: 09 December 2016 16:33
> To: Bill Fenner
> Cc: ipsec@ietf.org; suns...@ietf.org
> Subject: Re: [sunset4] ietf-nat64 - Internet VPN clients
> 
> On 9 Dec 2016, at 16:07, Bill Fenner wrote:
> 
>> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick <nick.heat...@ee.co.uk>
>> wrote:
>> 
>>> Hi All,
>>> 
>>> The sunset4 minutes suggest NAT64 SSID to become the default?
>>> 
>>> Just checking, is there any summary on how VPN clients behaved on the
>>> nat64 SSID following the event?
>>> 
>> 
>> Just an anecdote, not actual information: I have two different ways to 
>> contact my office VPN server (SSL VPN and IPSEC); neither one worked 
>> from NAT64.  The vendor documentation says that they don't support 
>> IPv6 transport for the SSL VPN; I do not know what went wrong with the 
>> IPSEC VPN.  The vendor introduced support for IPSEC with v6 transport 
>> in their newest software, to which we'll upgrade soon; perhaps that 
>> upgrade will include whatever is required for it to work through NAT64 
>> too.  Their support matrix still says that even the newest software 
>> does not support SSL VPN over IPv6.
> 
> That’s maybe for the ipsec wg but while native IPv6 VPN has been working fine 
> for me for ages, how would a NAT64 policy exchange actually look like (I am 
> thinking about what is done for IPv4 NAT or double NAT within the same 
> address family);  I doubt that different AFs on each end as part of the 
> policy are specified to work, so I’d not expect IPsec VPNs to work across a 
> NAT64 (from a v6 to a v4 endpoint);  someone surprise me and say with IKEv2 
> you can?  Someone surprise me and say with a double NAT64 it can work?
> 
> /bz
> 
> ___
> sunset4 mailing list
> suns...@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4
> 
> NOTICE AND DISCLAIMER
> This email contains BT information, which may be privileged or confidential. 
> It's meant only for the individual(s) or entity named above. 
> If you're not the intended recipient, note that disclosing, copying, 
> distributing or using this information is prohibited. 
> If you've received this email in error, please let me know immediately on the 
> email address above. Thank you.
> 
> We monitor our email system, and may record your emails.
> 
> EE Limited 
> Registered office:Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 
> 9BW
> Registered in England no: 02382161
> 
> EE Limited is a wholly owned subsidiary of:
> 
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 180
> ___
> 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] draft-ietf-ipsecme-tcp-encaps-04.txt

[Tommy Pauly]

Thanks for confirming! I appreciate all of your help in cleaning this part up!

Tommy

> On Dec 7, 2016, at 11:52 AM, Hu, Jun (Nokia - US) <jun...@nokia.com> wrote:
> 
> Looks good to me
> 
>> -Original Message-
>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tommy Pauly
>> Sent: Sunday, December 04, 2016 3:07 PM
>> To: IPsecME WG <ipsec@ietf.org>
>> Subject: [IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt
>> 
>> Hello all,
>> 
>> I've updated the TCP Encapsulation draft with new recommendations around
>> handling the mapping between IKE SAs and TCP Connections based on the
>> conversation at the Seoul meeting. The relevant new text in section 6 is:
>> 
>> 
>> An initiator SHOULD only open one TCP connection per IKE SA, over
>>   which it sends all of the corresponding IKE and ESP messages.  This
>>   helps ensure that any firewall or NAT mappings allocated for the TCP
>>   connection apply to all of the traffic associated with the IKE SA
>>   equally.
>> 
>>   A responder SHOULD at any given time send packets for an IKE SA and
>>   its Child SAs over only one TCP connection.  It should choose the TCP
>>   connection on which it last received a valid and decryptable IKE or
>>   ESP message.  Since a connection may be broken and a new connection
>>   re-established by the initiator without the responder being aware, a
>>   responder SHOULD accept receiving IKE and ESP messages on a new
>>   connection.  It will then use that connection for all subsequent
>>   responses.  A responder MAY close a TCP connection that it perceives
>>   as idle and extraneous (one previously used for IKE and ESP messages
>>   that has been replaced by a new connection).
>> 
>>   Multiple IKE SAs SHOULD NOT share a single TCP connection.
>> 
>> Please respond to indicate your thoughts on this!
>> 
>> Thanks,
>> Tommy
>> 
>> 
>>> On Dec 4, 2016, at 3:04 PM, internet-dra...@ietf.org wrote:
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the IP Security Maintenance and Extensions of 
>>> the
>> IETF.
>>> 
>>>   Title   : TCP Encapsulation of IKE and IPsec Packets
>>>   Authors : Tommy Pauly
>>> Samy Touati
>>> Ravi Mantha
>>> Filename: draft-ietf-ipsecme-tcp-encaps-04.txt
>>> Pages   : 21
>>> Date: 2016-12-04
>>> 
>>> Abstract:
>>>  This document describes a method to transport IKE and IPsec packets
>>>  over a TCP connection for traversing network middleboxes that may
>>>  block IKE negotiation over UDP.  This method, referred to as TCP
>>>  encapsulation, involves sending both IKE packets for tunnel
>>>  establishment as well as tunneled packets using ESP over a TCP
>>>  connection.  This method is intended to be used as a fallback option
>>>  when IKE cannot be negotiated over UDP.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
>>> 
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-04
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-04
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at 
>>> tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> ___
>>> 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

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

[IPsec] draft-ietf-ipsecme-tcp-encaps-04.txt

[Tommy Pauly]

Hello all,

I've updated the TCP Encapsulation draft with new recommendations around 
handling the mapping between IKE SAs and TCP Connections based on the 
conversation at the Seoul meeting. The relevant new text in section 6 is:

 
An initiator SHOULD only open one TCP connection per IKE SA, over
   which it sends all of the corresponding IKE and ESP messages.  This
   helps ensure that any firewall or NAT mappings allocated for the TCP
   connection apply to all of the traffic associated with the IKE SA
   equally.

   A responder SHOULD at any given time send packets for an IKE SA and
   its Child SAs over only one TCP connection.  It should choose the TCP
   connection on which it last received a valid and decryptable IKE or
   ESP message.  Since a connection may be broken and a new connection
   re-established by the initiator without the responder being aware, a
   responder SHOULD accept receiving IKE and ESP messages on a new
   connection.  It will then use that connection for all subsequent
   responses.  A responder MAY close a TCP connection that it perceives
   as idle and extraneous (one previously used for IKE and ESP messages
   that has been replaced by a new connection).

   Multiple IKE SAs SHOULD NOT share a single TCP connection.

Please respond to indicate your thoughts on this!

Thanks,
Tommy


> On Dec 4, 2016, at 3:04 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions of 
> the IETF.
> 
>Title   : TCP Encapsulation of IKE and IPsec Packets
>    Authors : Tommy Pauly
>  Samy Touati
>  Ravi Mantha
>   Filename: draft-ietf-ipsecme-tcp-encaps-04.txt
>   Pages   : 21
>   Date: 2016-12-04
> 
> Abstract:
>   This document describes a method to transport IKE and IPsec packets
>   over a TCP connection for traversing network middleboxes that may
>   block IKE negotiation over UDP.  This method, referred to as TCP
>   encapsulation, involves sending both IKE packets for tunnel
>   establishment as well as tunneled packets using ESP over a TCP
>   connection.  This method is intended to be used as a fallback option
>   when IKE cannot be negotiated over UDP.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] I-D Action: draft-ietf-ipsecme-eddsa-00.txt

[Tommy Pauly]

Hi Yoav,

Thanks for posting this. The draft looks good, and we're eager to see this move 
along! If you have an implementation already supporting this, I'd be interested 
in testing interop.

I think the reservation of the 0 IANA hash value for the "Identity" hash makes 
sense; since it seems pretty straightforward, is there a possibility of getting 
this reserved soon?

Thanks,
Tommy

> On Oct 29, 2016, at 8:19 AM, Yoav Nir  wrote:
> 
> This version is similar to draft-nir-ipsecme-eddsa-01, with the following 
> changes:
> Updated references
> Removed the title of the Curdle draft from the text because it had become 
> unwieldy [1]
> Updated the OIDs in appendix A and added a binary representation as in RFC 
> 7427
> Added some text in IANA considerations
> 
> The XML source is now in 
> https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-eddsa.xml
>  
> 
> 
> Yoav
> 
> [1] Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and 
> X448 for use in the Internet X.509 Public Key Infrastructure
> 
>> On 28 Oct 2016, at 22:54, internet-dra...@ietf.org 
>>  wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the IP Security Maintenance and Extensions of 
>> the IETF.
>> 
>>Title   : Using Edwards-curve Digital Signature Algorithm 
>> (EdDSA) in the Internet Key Exchange (IKEv2)
>>Author  : Yoav Nir
>>  Filename: draft-ietf-ipsecme-eddsa-00.txt
>>  Pages   : 5
>>  Date: 2016-10-28
>> 
>> Abstract:
>>   This document describes the use of the Edwards-curve digital
>>   signature algorithm in the IKEv2 protocol.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ 
>> 
>> 
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-00
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> ___
>> 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

[IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt

[Tommy Pauly]

Hello,

I’ve posted a new version of the TCP encapsulation draft with the following 
changes:

1. Added a section to explicitly discuss how to fallback from UDP to TCP 
(retransmissions, etc) based on feedback from the charter discussion
2. Explained that this method of encapsulation can be used for any stream 
protocol, and is not TCP specific, based on feedback from the charter discussion
3. Clarified the use of multiple TCP connections for Child SAs, based on Jun 
Hu’s questions

Also, I’m happy to say that we’ve been doing interoperability testing between 
Apple clients and Cisco server for TCP encapsulation. If anyone else has an 
implementation they’d like to try out, please let us know!

Best,
Tommy

> On Oct 31, 2016, at 8:56 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions of 
> the IETF.
> 
>Title   : TCP Encapsulation of IKE and IPsec Packets
>    Authors : Tommy Pauly
>  Samy Touati
>  Ravi Mantha
>   Filename: draft-ietf-ipsecme-tcp-encaps-03.txt
>   Pages   : 20
>   Date: 2016-10-31
> 
> Abstract:
>   This document describes a method to transport IKE and IPsec packets
>   over a TCP connection for traversing network middleboxes that may
>   block IKE negotiation over UDP.  This method, referred to as TCP
>   encapsulation, involves sending both IKE packets for tunnel
>   establishment as well as tunneled packets using ESP over a TCP
>   connection.  This method is intended to be used as a fallback option
>   when IKE cannot be negotiated over UDP.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] New version of TCP Encapsulation draft, request for adoption

[Tommy Pauly]

Hi Jun,

You’re correct that the draft does not specifically call out using multiple TCP 
connections for a single Child SA. It explains that one reason to use multiple 
TCP connections is to handle “connect[ing] to multiple gateways handling 
different ESP SAs”, which is the one-child-SA-per-TCP model. There is nothing 
in the protocol prohibiting using multiple TCP connections for a single child 
SA; what is your main use case here? Is there something that you find useful in 
that that could perhaps help inform this clarifying text?

Tommy

> On Oct 11, 2016, at 8:42 PM, Hu, Jun (Nokia - US) <jun...@nokia.com> wrote:
> 
> From the section 6 text, my understanding is draft allows multiple TCP 
> connections for a given tunnel which includes multiple CHILD_SAs; however it 
> is not clear to me that draft also allows multiple TCP session for a single 
> SA, is there any use case of having multiple TCP sessions for a single 
> CHILD_SA?
>  
>  
> From: tpa...@apple.com [mailto:tpa...@apple.com] 
> Sent: Tuesday, October 11, 2016 5:35 PM
> To: Hu, Jun (Nokia - US)
> Cc: Valery Smyslov; Yoav Nir; IPsecME WG; Daniel Migault; Paul Wouters
> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for 
> adoption
>  
> Please see section 6:
>  
>  Multiple TCP connections between the initiator and the responder are
>allowed, but their use must take into account the initiator
>capabilities and the deployment model such as to connect to multiple
>gateways handling different ESP SAs when deployed in a high
>availability model.  It is also possible to negotiate multiple IKE
>SAs over the same TCP connection.
>  
>The processing of the TCP packets is the same whether its within a
>single or multiple TCP connections.
> 
> We believe this text is fairly direct in specifying that multiple IKE SAs can 
> go over a single TCP stream, and that multiple TCP streams are allowed for a 
> single IKE SA/Child SA set. There is no dependency between the TCP streams 
> and the IKE or Child SAs. We recommend a 1-to-1 correspondence for 
> simplicity, but there is no technical limitation. The TCP streams should not 
> necessarily be closed or reset if the SA sends data on a different flow.
> 
> Thanks,
> Tommy
>  
>  
> On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) <jun...@nokia.com 
> <mailto:jun...@nokia.com>> wrote:
>  
> Any comments to my questions below?
> Does draft allows multiple TCP sessions for a given SA? Or it should be only 
> one TCP session allowed for a given SA?
> 
> 
> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] 
> On Behalf Of Hu, Jun (Nokia - US)
> Sent: Friday, October 07, 2016 2:09 PM
> To: Tommy Pauly; Valery Smyslov; Yoav Nir
> Cc: IPsecME WG; Daniel Migault; Paul Wouters
> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for
> adoption
> 
> I was reading the draft again, and had similar problem as below; Draft states
> that SA state should be independent of TCP state and it allows multiple TCP
> sessions between two peers even when there is only one IKE_SA; I assume this
> means for a given tunnel, different SA could belong to different TCP session,
> e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does
> this mean draft allows multiple TCP sessions for a given SA? I guess not, if
> that's the case, then it should be stated clearly in the draft that for a 
> given SA,
> only one TCP session is allowed; In case of when the original initiator lost 
> TCP
> session and create a new one, the responder should update its TCP_session-
> to-SA binding after it receives a valid IKE/ESP packet is received on the new
> TCP session and close the old one, send TCP RST
> 
> 
> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] 
> On Behalf Of Tommy Pauly
> ...
> 
> 
> Then, I think some text should be added describing a situation when
> the original responder having a valid (from its point of view) TCP
> session receives a request from original initiator for a new TCP
> session. This may happen if original initiator looses TCP state for
> some reason (RST from an attacker, temporary network failure etc.).
> In this case the responder will have two TCP sessions associated
> with the IKE SA. Clearly, the new one should be used for further
> communications, but only after it is proven to be authentic (some
> protected message is received over it). But what the responder
> should do
> with the old TCP session?
> 
> Keep it? Send FIN? Send RST? Just discard?
> 
> 
> In general, the approach of the draft is to clearly separate

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt

[Tommy Pauly]

Hi Daniel,

Thanks for sending this out! Definitely very interesting stuff. I like the new 
focus on how to compress UDP/TCP within Diet-ESP.

Some of the introduction text could use some clarification/wordsmithing:

IPsec/ESP has not been designed to reduce the networking overhead of
   the communications.  In fact saving bandwidth comes with additional
   operation that may affect or impact large infrastructure where
   bandwidth usage is not an issue.  On the other hand, IoT emerged with
   completely different constraints.  IoT communications are different
   in many ways and a few important differences may be that sending any
   extra byte impact significantly the life time of these devices.  In
   addition, these devices are also expected to be sleeping nodes where
   communications are hardly based on sessions as we used to.

Perhaps could be:

IPsec/ESP was not designed to reduce the networking overhead of
   the communications.  In fact, reducing bandwidth often adds computational
   overhead that may negatively impact large infrastructures in which
   bandwidth usage is not a constraint.  On the other hand, IoT devices have
   completely different constraints.  In IoT communications, sending any
   extra bytes can significantly impact the battery life of devices.  These 
devices
   are also often expected to be sleeping nodes, for which IPsec sessions
   have a very different meaning.


I think the work on the appendices to provide more full examples of how the 
packets are compressed is very effective. Thanks for adding that. I did find it 
a bit confusing that the packet diagrams don’t give a clear picture of the 
effect of encryption on inner packet data. In the RFC 4303 diagrams, the 
‘inner’ portions are all summarized as ‘Payload Data’, which is the content 
that is encrypted. In your diagrams, we see the decrypted content written out. 
Perhaps there is some labelling on the figures you can add to make that a bit 
clearer?

Thanks,
Tommy

> On Oct 12, 2016, at 11:50 AM, Daniel Migault  
> wrote:
> 
> Hi, 
> 
> Please find an update version of the diet-esp document we discussed in 
> Berlin. The scope of the compression has been extended, and the compression 
> simplified. We also provided example in the appendix section.
> 
> Comments are welcome as usual!
> 
> BR, 
> Daniel
> 
> -Ursprüngliche Nachricht-
> Von: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
> Gesendet: Mittwoch, 12. Oktober 2016 19:45
> An: Carsten Bormann ; Daniel Migault 
> ; Tobias Guggemos 
> Betreff: New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt
> 
> 
> A new version of I-D, draft-mglt-ipsecme-diet-esp-02.txt
> has been successfully submitted by Daniel Migault and posted to the IETF 
> repository.
> 
> Name: draft-mglt-ipsecme-diet-esp
> Revision: 02
> Title:ESP Header Compression and Diet-ESP
> Document date:2016-10-04
> Group:Individual Submission
> Pages:43
> URL:
> https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-diet-esp-02.txt
> Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/
> Htmlized:   https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-02
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-diet-esp-02
> 
> Abstract:
>   ESP Header Compression (EHC) defines a flexible framework to compress
>   communications protected with IPsec/ESP.  Compression and
>   decompression is defined by EHC Rules orchestrated by EHC Strategies.
> 
>   The document specifies the Diet-ESP EHC Strategy and associated EHC
>   Rules.  Diet-ESP compresses up to 32 bytes per packet for traditional
>   IPv6 VPN and up to 66 bytes for IPv6 VPN set over a single TCP or UDP
>   session.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> ___
> 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] New version of TCP Encapsulation draft, request for adoption

[Tommy Pauly]

Please see section 6:

 Multiple TCP connections between the initiator and the responder are
   allowed, but their use must take into account the initiator
   capabilities and the deployment model such as to connect to multiple
   gateways handling different ESP SAs when deployed in a high
   availability model.  It is also possible to negotiate multiple IKE
   SAs over the same TCP connection.

   The processing of the TCP packets is the same whether its within a
   single or multiple TCP connections.

We believe this text is fairly direct in specifying that multiple IKE SAs can 
go over a single TCP stream, and that multiple TCP streams are allowed for a 
single IKE SA/Child SA set. There is no dependency between the TCP streams and 
the IKE or Child SAs. We recommend a 1-to-1 correspondence for simplicity, but 
there is no technical limitation. The TCP streams should not necessarily be 
closed or reset if the SA sends data on a different flow.

Thanks,
Tommy


> On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) <jun...@nokia.com> wrote:
> 
> Any comments to my questions below?
> Does draft allows multiple TCP sessions for a given SA? Or it should be only 
> one TCP session allowed for a given SA?
> 
>> -Original Message-
>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Hu, Jun (Nokia - US)
>> Sent: Friday, October 07, 2016 2:09 PM
>> To: Tommy Pauly; Valery Smyslov; Yoav Nir
>> Cc: IPsecME WG; Daniel Migault; Paul Wouters
>> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for
>> adoption
>> 
>> I was reading the draft again, and had similar problem as below; Draft states
>> that SA state should be independent of TCP state and it allows multiple TCP
>> sessions between two peers even when there is only one IKE_SA; I assume this
>> means for a given tunnel, different SA could belong to different TCP session,
>> e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does
>> this mean draft allows multiple TCP sessions for a given SA? I guess not, if
>> that's the case, then it should be stated clearly in the draft that for a 
>> given SA,
>> only one TCP session is allowed; In case of when the original initiator lost 
>> TCP
>> session and create a new one, the responder should update its TCP_session-
>> to-SA binding after it receives a valid IKE/ESP packet is received on the new
>> TCP session and close the old one, send TCP RST
>> 
>>> -Original Message-
>>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tommy Pauly
>> ...
>> 
>>>> Then, I think some text should be added describing a situation when
>>>> the original responder having a valid (from its point of view) TCP
>>>> session receives a request from original initiator for a new TCP
>>>> session. This may happen if original initiator looses TCP state for
>>>> some reason (RST from an attacker, temporary network failure etc.).
>>>> In this case the responder will have two TCP sessions associated
>>>> with the IKE SA. Clearly, the new one should be used for further
>>>> communications, but only after it is proven to be authentic (some
>>>> protected message is received over it). But what the responder
>>>> should do
>>> with the old TCP session?
>>>> Keep it? Send FIN? Send RST? Just discard?
>>>> 
>>> 
>>> In general, the approach of the draft is to clearly separate the TCP
>>> state from the IKE session state. If you look at Section 6, it
>>> specifically allows for multiple TCP connections between two peers
>>> even if there is only one IKE SA between them. If one of them becomes
>>> redundant (because the other peer opened up a new TCP flow for some
>>> reason), it would make sense to close the other in a usual way. I
>>> think this can be left to the implementation, but either a FIN or RST would 
>>> be
>> appropriate rather than a discard. We can add that to future versions.
>>> 
>> 
>> ___
>> 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

[IPsec] New Version of Split DNS for IKEv2

[Tommy Pauly]

Hello all,

We've posted a new version of draft-pauly-ipsecme-split-dns 
(https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02).

The changes in this version include:

- Textual clarification based on input from Daniel and Tero
- Clarification of DNSSEC payload types
- Update on the content and structure of the INTERNAL_DNSSEC_TA 
attribute
- How to associate DNSSEC values with specific domains
- Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS)

We believe this should be ready for adoption and moving forward, to follow the 
charter. Please review and provide your input!

Thanks,
Tommy


> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-pauly-ipsecme-split-dns-02.txt
> Date: September 21, 2016 at 1:27:23 PM PDT
> To: Tommy Pauly <tpa...@apple.com>, Paul Wouters <pwout...@redhat.com>
> 
> 
> A new version of I-D, draft-pauly-ipsecme-split-dns-02.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
> 
> Name: draft-pauly-ipsecme-split-dns
> Revision: 02
> Title:Split DNS Configuration for IKEv2 
> Document date:2016-09-21
> Group:Individual Submission
> Pages:12
> URL:
> https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/
> Htmlized:   https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-pauly-ipsecme-split-dns-02
> 
> Abstract:
>   This document defines two Configuration Payload Attribute Types for
>   the IKEv2 protocol that add support for private DNS domains.  These
>   domains should be resolved using DNS servers reachable through an
>   IPsec connection, while leaving all other DNS resolution unchanged.
>   This approach of resolving a subset of domains using non-public DNS
>   servers is referred to as "Split DNS".
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

Re: [IPsec] Mirja Kühlewind's Block on charter-ietf-ipsecme-10-00: (with BLOCK)

[Tommy Pauly]

Hi Kathleen,

> On Aug 31, 2016, at 6:53 PM, Kathleen Moriarty 
> <kathleen.moriarty.i...@gmail.com> wrote:
> 
> Tommy,
> 
> On Wed, Aug 31, 2016 at 10:30 AM, Tommy Pauly <tpa...@apple.com 
> <mailto:tpa...@apple.com>> wrote:
>> 
>>> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF) <i...@kuehlewind.net> 
>>> wrote:
>>> 
>>> Hi all,
>>> 
>>> thanks for providing the reference to the draft. That was very helpful and 
>>> confirmed my initial assumption that you don’t want to ‚change‘ TCP. So 
>>> this work seems to be fine in this group, however, the wording in the 
>>> charter is very misleading. What's about the following?
>>> 
>>> "There have been middle boxes blocking IKE negotiation over UDP. To
>>> make IKE work in these environments, IKE packets need to be
>>> encapsulated in ESP over TCP. Therefore the group will define a mechanism to
>>> use IKE and IPsec over TCP. Further the group will provide guidance
>>> how to detect when IKE cannot be negotiated over UDP and TCP as a fallback 
>>> should be used.“
>>> 
>>> I also removed some redundancy and added a point that guidance is needed to 
>>> detect blocking. We could still at the current draft as a starting point…
>> 
>> "IKE packets need to be encapsulated in ESP over TCP" is not correct, since 
>> IKE does not run over ESP. IKE and ESP packets run alongside one another in 
>> the stream, as they do when using UDP encapsulation.
>> 
>> How about:
>> 
>> "There have been middle boxes blocking IKE negotiation over UDP. To
>> make IKE work in these environments, both IKE packets and tunneled ESP
>> packets need to be encapsulated in TCP. Therefore the group will define
>> a mechanism to use IKE and IPsec over TCP, and define the scenarios
>> in which it is appropriate to use this method."
> 
> Are you okay with Tero's proposed wording since Mirja has agreed to
> it.  The suggested wording is:
> 
> There have been middle boxes blocking IKE negotiation over UDP. To
> make IKE work in these environments, IKE and ESP packets need to be
> transmitted over TCP. Therefore the group will define a mechanism to
> use IKE and IPsec over TCP. Further the group will provide guidance
> how to detect when IKE cannot be negotiated over UDP and TCP as a
> fallback should be used.

The final sentence seems like it's missing a word after "guidance":

"Further the group will provide guidance
how to detect when IKE cannot be negotiated over UDP and TCP as a
fallback should be used."

How about:

"The group will also provide guidance on how to detect when IKE cannot be 
negotiated over UDP, and TCP should be used as a fallback".

From a content perspective, I am fine with this as long as the primary draft 
leaves the algorithm as a fairly open-ended suggestion. I think it is 
appropriate to say that the IKE_SA_INIT should be sent over UDP several times, 
after which point a fallback to TCP is appropriate if so configured on the 
device (and that this fallback may be sooner if there is historical reason to 
believe it is necessary). Any more specifics about timing and how to measure 
expected response times, etc, would be out of scope. Does that work?

Thanks,
Tommy

> 
> Sorry for my delayed response to make sure this was addressed, I was
> off today and driving for a good portion of the day.
> 
> Thanks,
> Kathleen
> 
>> 
>> The draft covers the applicability of TCP encapsulation, but I strongly 
>> believe that specific algorithm for fallback is out of scope. This will be 
>> highly context-dependent, and we will have different algorithms for 
>> different devices and scenarios. I have planned on writing an informational 
>> draft as a follow-on to describe the methods we use, but that should be 
>> independent of the protocol to define the IKE/ESP messages in a stream, 
>> which is a much more general protocol.
>> 
>> Thanks,
>> Tommy
>> 
>>> 
>>> Mirja
>>> 
>>> 
>>>> Am 31.08.2016 um 15:17 schrieb Yoav Nir <ynir.i...@gmail.com>:
>>>> 
>>>> 
>>>>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen <kivi...@iki.fi> wrote:
>>>>> 
>>>>> Mirja Kuehlewind (IETF) writes:
>>>>>> thanks for the reply. Very helpful background info. Maybe even put
>>>>>> more information in the charter text.
>>>>> 
>>>>> I think it belongs to the actual draft, not to the charter, perhaps we
>>>>> should put the draft-ietf-ipsecm

Re: [IPsec] Mirja Kühlewind's Block on charter-ietf-ipsecme-10-00: (with BLOCK)

[Tommy Pauly]

> On Aug 31, 2016, at 6:41 AM, Mirja Kuehlewind (IETF)  
> wrote:
> 
> Hi all,
> 
> thanks for providing the reference to the draft. That was very helpful and 
> confirmed my initial assumption that you don’t want to ‚change‘ TCP. So this 
> work seems to be fine in this group, however, the wording in the charter is 
> very misleading. What's about the following?
> 
> "There have been middle boxes blocking IKE negotiation over UDP. To
> make IKE work in these environments, IKE packets need to be
> encapsulated in ESP over TCP. Therefore the group will define a mechanism to
> use IKE and IPsec over TCP. Further the group will provide guidance 
> how to detect when IKE cannot be negotiated over UDP and TCP as a fallback 
> should be used.“
> 
> I also removed some redundancy and added a point that guidance is needed to 
> detect blocking. We could still at the current draft as a starting point…

"IKE packets need to be encapsulated in ESP over TCP" is not correct, since IKE 
does not run over ESP. IKE and ESP packets run alongside one another in the 
stream, as they do when using UDP encapsulation.

How about:

"There have been middle boxes blocking IKE negotiation over UDP. To
make IKE work in these environments, both IKE packets and tunneled ESP
packets need to be encapsulated in TCP. Therefore the group will define 
a mechanism to use IKE and IPsec over TCP, and define the scenarios
in which it is appropriate to use this method."

The draft covers the applicability of TCP encapsulation, but I strongly believe 
that specific algorithm for fallback is out of scope. This will be highly 
context-dependent, and we will have different algorithms for different devices 
and scenarios. I have planned on writing an informational draft as a follow-on 
to describe the methods we use, but that should be independent of the protocol 
to define the IKE/ESP messages in a stream, which is a much more general 
protocol.

Thanks,
Tommy

> 
> Mirja
> 
> 
>> Am 31.08.2016 um 15:17 schrieb Yoav Nir :
>> 
>> 
>>> On 31 Aug 2016, at 3:21 PM, Tero Kivinen  wrote:
>>> 
>>> Mirja Kuehlewind (IETF) writes:
 thanks for the reply. Very helpful background info. Maybe even put
 more information in the charter text. 
>>> 
>>> I think it belongs to the actual draft, not to the charter, perhaps we
>>> should put the draft-ietf-ipsecme-tcp-encaps in the charter, as
>>> a working draft. 
>>> 
 When you say "the 3gpp specification did not consider or specify all
 needed things for the protocol“, can you be more specific here?
>>> 
>>> 3GPP just said that we make TCP tunnel, put 16-bit length header in
>>> front telling the length of the IKE or ESP packet coming after that,
>>> and then we put either ESP packet directly, or 4-bytes of zeros
>>> (Non-ESP marker we use in UDP encapsulation) and IKE packet.
>>> 
>>> There is also keepalive timer sending packets over TCP to keep it
>>> alive (again similar what we have in UDP).
>> 
>> One more bit of information: some vendors have had a non-standardized 
>> version of this or something similar for years. My employer has had it since 
>> 2003, except that the header is a bit different. The pretty ubiquitous SSL 
>> VPNs do pretty much the same except that they encrypt IP packets plus 
>> headers into TLS records rather than ESP packets before streaming them over 
>> TCP.
>> 
>> Perhaps “TCP tunnel” is a misleading term because the TCP does not tunnel. 
>> That is part of the function of ESP. Perhaps we should be saying “TCP 
>> streaming of ESP and IKE packets”
>> 
>> Yoav
> 
> ___
> 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] Spencer Dawkins' No Objection on charter-ietf-ipsecme-10-00: (with COMMENT)

[Tommy Pauly]

> On Aug 31, 2016, at 3:23 AM, Tero Kivinen  wrote:
> 
> Kathleen Moriarty writes:
 "There have been middle boxes blocking IKE negotiation over UDP. To
 make IKE work in these environments, IKE packets need to be
 encapsulated in a TCP tunnel.
>>> 
>>> 
>>> "In a TCP tunnel" is perhaps a little confusing, as IPinIP or an IPsec
>>> tunnel was not meant. Instead, we meant "encapsulated in TCP".
>> 
>> OK, I am changing this text too, thanks.
>>> 
 The group will define a mechanism to
 tunnel IKE and IPsec over a TCP-based connection. This method is
 intended to be used as a fallback when IKE cannot be negotiated over
 UDP. The group will create a method where IKEv2 and IPsec packets can
 be encapsulated in the TCP connection."
>>> 
>>> 
>>> 
 going for external review, but I'd love to understand better what the
 resulting protocol stack looks like. I get the part about encapsulating
 IKEv2 in TCP, but is encapsulating IPsec in TCP going to give us a
 general-purpose "IP over TCP" mechanism?

In effect, yes: we prefer that IKE/IPSec tunnels are run over UDP for various 
reasons (performance, etc), but having a fallback over TCP allows it to be a 
generic tunneling mechanism over TCP, such that implementations can use this as 
a standardized VPN that works on UDP or TCP, and not need a proprietary 
protocol.

>>> 
>>> 
>>> It will be "ESP over TCP" similar to how we now have "ESP over UDP".
>> 
>> We should be more explicit here, I agree with Spencer.  The IKE part
>> is clear since that's UPD 500.  Would this be transport mode ESP only?
>> If that's the case, how is the following alteration to the text:
>> 
>> The group will define a mechanism to
>> tunnel IKE and IPsec over a TCP-based connection. This method is
>> intended to be used as a fallback when IKE cannot be negotiated over
>> UDP. The group will create a method where IKEv2 and IPsec ESP
>> transport mode packets can
>> be encapsulated in the TCP connection."
>> 
>> Working group: If I've changed the intent too much, please suggest
>> other wording.
> 
> The traffic inside the TCP-based connection is usually ESP tunnel
> mode, not transport mode, so the change you made is limiting it too
> much.
> 
> I.e., this is intended for mobile phones / laptops etc doing VPN
> connection from the hotel to the enterprice vpn gateway and where the
> hotel etc firewall blocks all UDP traffic. So when UDP does not work
> we make TCP connection and encapsulate all IKE and ESP packets to that
> TCP connection. On those cases the VPN gateway usually assigns
> internal IP-address to the mobile device using configuration payloads
> in IKE, and then the mobile device uses tunnel mode ESP to send data
> to the internal enterprice network. 
> 
> So at least remove the "transport mode" and then it should be ok. 

Right. If we would specific any mode specifically, it should specify tunnel 
mode, not transport mode.

The proposed change to the text is fine apart from the specification of the 
mode!

Thanks,
Tommy

> 
> The protocol stack will look like this:
> 
>  Data packet: IKEv2 packet
> 
>  Application data
>  TCP header   IKEv2 packet
>  Inner IP-header  IKEv2 header
>  ESP  Non-ESP Marker
>  Length   Length
>  TCP header   TCP header
>  Outer IP-header  Outer IP-header
> 
> (Of course as this runs over normal TCP connection, the Length ESP +
> Inner IP-header + TCP header + Application data might get splitted to
> multiple actual packets, or there might be multiple inner packets
> inside the same TCP packet).
> 
> This is similar than what we already have when doing UDP encapsulation
> of IPsec (RFC3948):
> 
> 3.4.  Tunnel Mode ESP Encapsulation
> ...
> AFTER APPLYING ESP/UDP
>--
>   IPv4 |new h.| UDP | ESP |orig IP hdr  | |  |   ESP   | ESP|
>|(opts)| Hdr | Hdr |(any options)| TCP | Data | Trailer |Auth|
>--
>   |< encrypted --->|
> |<- authenticated >|
> 
> but instead of "UDP Hdr" we have TCP connection.
> -- 
> 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] review for draft-ietf-ipsecme-tcp-encaps-01

[Tommy Pauly]

Hi Daniel,

Thanks for the in-depth review! I've incorporated your comments into a new 
update: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-02 
. Specific 
responses to your comments inline!

Any other comments are welcome on the new version. I agree with Daniel that 
we're in good shape to go into WGLC.

Best,
Tommy

> On Jul 27, 2016, at 11:24 AM, Daniel Migault  
> wrote:
> 
> Hi, 
> 
> I reviewed draft-ietf-ipsecme-tcp-encaps-01 as my understanding is that we 
> are doing a pre-WGLC.  I think the draft is in pretty good shape for a WGLC. 
> Please see my comments below. 
> 
> 
> BR, 
> Daniel
> 
>TCP Encapsulation of IKE and IPSec Packets
> draft-ietf-ipsecme-tcp-encaps-01
> 
> Abstract
> 
>This document describes a method to transport IKE and IPSec packets
>over a TCP connection for traversing network middleboxes that may
>block IKE negotiation over UDP.  This method, referred to as TCP
>encapsulation, involves sending all packets for tunnel establishment
>  
> >MGLT: Maybe that would be clearer to have:
> >OLD:
> >This method, referred to as TCP
> >encapsulation, involves sending all packets for tunnel establishment
> >as well as tunneled packets over a TCP connection. 
> >
> >NEW:
> >This method, referred to as TCP
> >encapsulation, involves both sending all IKE packets for tunnel establishment
> >as well as tunneled packets with ESP over a TCP connection. 

Tweaked the wording, thanks!
> 
>
>as well as tunneled packets over a TCP connection.  This method is
>intended to be used as a fallback option when IKE cannot be
>negotiated over UDP.
> 
> 
> 1.  Introduction
> 
>IKEv2 [RFC7296] is a protocol for establishing IPSec tunnels, using
>
> >MGLT: I think IPSec should be replaced by IPsec.

Replaced throughout the draft. Thanks for pointing this out.

>  
>Direct use of ESP or UDP Encapsulation should be preferred by IKE
>implementations due to performance concerns when using TCP
>Encapsulation Section 12.
>
> >MGLT: This looks a bit strange to have Section 12 at the end of the 
> >sentence. Maye it would be preferred something like "More details 
> >are provided in Section 12" 

Adjusted formatting.
> 
>Most implementations should use TCP
>Encapsulation only on networks where negotiation over UDP has been
>attempted without receiving responses from the peer, or if a network
>is known to not support UDP.
> 
> 1.1.  Prior Work and Motivation
> 
> 
>Some previous solutions include:
> 
> >MGLT: I would prefer "alternatives" then "solutions" as solutions 
> > imply there is not anymore a problem to solve.. In addition, we 
> >can add some justification for this document. The justifications for 
> >me are 1) defining a standard that provides interoperability as well 
> >as 2) reduce the additional overhead over some tof the solutions. I 
> >do not know if that is easier to have a sentence to position the 
> >document toward each alternative or if it can be summed up in the
>  >beginning. 
>  

I switched the wording to "alternatives", and added some text after the list 
about the goal of this document with regards to how it is different from other 
approaches.

> 
> 
> 2.  Configuration
> 
>One of the main reasons to use TCP encapsulation is that UDP traffic
>may be entirely blocked on a network.  Because of this, support for
>TCP encapsulation is not specifically negotiated in the IKE exchange.
>Instead, support for TCP encapsulation must be pre-configured on both
>the initiator and the responder.
> 
>The configuration defined on each peer should include the following
>parameters:
> 
>o  One or more TCP ports on which the responder will listen for
>   incoming connections.  Note that the initiator may initiate TCP
>   connections to the responder from any local port.
> 
> >MGLT: I would also add a note that the port the responder
> >may listen to may be limited as such networks may only let
>  >a very limited set of outgoing ports over TCP. Obviously ports 
>  >could be 80 or 443. On the other hand on an IPsec point of 
>  >view port 4500 seems also a natural cnadidate. 

Added a note that the ports that will be chosen is likely based on the ones 
allowed on very restrictive networks.

>   
> 
>  
> 3.  TCP-Encapsulated Header Formats
> 
> >MGLT: Maybe it would help to specify in the begining of the section 
> >something like :
> >"TCP encapsulation follows
> >the UDP encapsulation marking to differentaite ESP to IKE. 
> >In addition, TCP stream also require the length to be specified."  
> >

Reworded the section to compare it to UDP encapsulation and point out the 
similarities.
>   In order to encapsulate IKE and ESP messages within a TCP stream, a
>16-bit length field precedes every message.  If the first 32-bits of
>the message are 

Re: [IPsec] Quantum Resistance Requirements

[Tommy Pauly]

Hi Scott,

Great list! Responses inline.

Best,
Tommy


> On Aug 11, 2016, at 3:00 PM, Scott Fluhrer (sfluhrer)  
> wrote:
> 
> In Berlin, we decided to take up Quantum Resistance as a work item, and that 
> we should start talking about requirements.  I’m starting this thread in a 
> hope of kicking off the discussion.
>  
> First of all, a solution to Quantum Resistance that is applicable everywhere 
> would involve replacing the (EC)DH exchange with a postquantum key exchange.  
> While this would be ideal, the cryptographical community currently doesn’t 
> have a solution that is sufficiently trusted and is of reasonable cost.  So, 
> it would make sense to divide this into two efforts, a long term solution 
> (which we may initially put on the shelf, as the crypto pieces aren’t there 
> yet), and a short term solution, to address the needs of customers that 
> aren’t willing to wait; instead, they feel the need to protect traffic that 
> is encrypted now.  For this short term solution, it’s sufficient if we don’t 
> necessarily cover all cases, a number of interesting cases (in particular, 
> ones for which redistributing secrets is doable) would be sufficient.  Does 
> everyone agree with that general assessment?
>  
> If so, there here is a list of potential requirements (based on Tero’s list 
> that he gave during the IETF, but with a few of my own), along with my 
> opinion:
>  
> -  Simplicity; how large of a change to IKE (and IKE implementations) 
> are we willing to contemplate?
> o   My opinion: minimizing changes to IKE should be given high priority, both 
> because “complexity is the enemy of security” and this is a short term 
> solution; if we have a solution that we can’t implement in a few years, well, 
> we might as well wait for the crypto people to give us the long term one.

Simplicity is definitely crucial to whatever solution we choose, and I think 
the current proposal of a pre shared key that gets mixed into the crypto is the 
simplest option we have now without really knowing what true QR algorithms will 
entail for IKE.

> -  Preserving existing IKE properties; how important is it that our 
> solution do not induce any weaknesses in IKE against an adversary with a 
> convention computer; that is, whatever we do, we must not make things worse?
> o   My opinion: I’m pretty sure that we’ll all agree that this is important 
> (except for possibly the identity protection, see below); I just want to 
> state this as something we need to remember.

Definitely important. 

> -  What do we feel needs to protected from someone with a Quantum 
> Computer?  Do we feel  the need to protect only the IPsec traffic, or do we 
> need to protect the IKE traffic as well.
> o   My opinion: I’m going to abstain on this one, except to note that 
> protecting only the IPsec traffic allows for a rather simple implementation; 
> now, if the WG decides that protecting the IKE traffic is important, this 
> simplicity is irrelevant.

My first reaction would be to focus on the IPSec traffic, which is clearly 
important. It's not clear yet if IKE being protected is useful; exactly how 
much more complicated will the exchange be, and is it worth it?

> -  What level of identity protection do we need to provide?  If two 
> different IKE negotiations use the same shared secret, do we mind if someone 
> can deduce that?
> o   My opinion: identity protection in IKE is rather overrated; I suspect 
> there’s enough in the data exchange that an advanced adversary (how can look 
> at things such as packet length and packet timings) is likely to get a fairly 
> decent guess regardless.

I agree that the aspect of identity protection is already a bit of a lost cause 
for this, and the new key will not significantly worsen the situation.


> -   PPK management; how much support do we provide for automatically 
> managing the secrets?
> o   My opinion: we already have preshared keys in IKE, and we don’t define 
> any particular management scheme for them (even though they are used quite 
> often in practice).  I don’t see why we need to go out of our way when it 
> comes to these postquantum secrets.

The management seems like a separate issue for deployments to figure out. I can 
imagine guidelines being published later, but let's just get the crypto spec 
out first.

> -  How much support do we provide for nonstatic secrets, for example, 
> by QKD, or via something like HIMMO (a key distribution mechanism that 
> appears to be post quantum)?
> o   My opinion: I’d prefer it if we didn’t spend a great deal of time trying 
> to come up with a solution that covers everything.  However, if we could 
> include a hook that these schemes could take advantage of (such as an opaque 
> identifier that’s passed that has meaning to the PPK manager), that might be 
> reasonable.
> -  Authentication; if someone with a Quantum Computer can break the 
> DH 

Re: [IPsec] New charter proposal

[Tommy Pauly]

> On Jul 20, 2016, at 5:12 PM, Valery Smyslov  wrote:
> 
> Hi, 
>> - Add Quantum Resistance for IKEv2 as new work item with milestone as
>> Feb 2017 for IETF LC.
> 
> This milestone looks a bit optimistic for me. Otherwise the updated chapter 
> looks good.

The issue seems fairly urgent in people’s minds right now, and the initial goal 
was expressed to be a fairly minimal level of changes to get basic QR 
properties (add support for a PPK to protect ESP traffic). The goal is 
optimistic, but hopefully achievable! There will probably be more ongoing QR 
work after that time.

Tommy

> 
> Regards,
> Valery.
> 
> ___
> 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] New charter proposal

[Tommy Pauly]

Looks good to me as well. Thanks!

Tommy

Sent from my iPhone

> On Jul 20, 2016, at 2:52 PM, Paul Wouters  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Jul 20, 2016, at 2:45 PM, Tero Kivinen  wrote:
>> 
>> As we discussed in the meeting yesterday, we need to update the
>> charter and we are making following changes to it:
> 
> Looks good
> 
> Paul
> 
> ___
> 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] New version of draft-ietf-ipsecme-rfc4307bis-10.txt

[Tommy Pauly]

Yes, this looks good! I think both RFCs in the columns makes sense. I agree 
that this looks ready for WGLC.

Tommy

> On Jul 20, 2016, at 1:40 PM, Paul Wouters  wrote:
> 
> On Wed, 20 Jul 2016, Tero Kivinen wrote:
> 
>> In the end I think the best option would be to just include both RFCs
>> in the references column, i.e. make the final table to be something
>> like this:
>> 
>>  Number Name  ESP Reference   IKEv2 Reference
>>  ...
>>  18 ENCR_AES_GCM_8[RFC4106][RFC]  [RFC5282][RFC]
>>  19 ENCR_AES_GCM_12   [RFC4106][RFC]  [RFC5282][RFC]
>>  20 ENCR_AES_GCM_16   [RFC4106][RFC]  [RFC5282][RFC]
>>  ...
>>  25 ENCR_CAMELLIA_CCM_8   [RFC5529][RFC]  -
>>  26 ENCR_CAMELLIA_CCM_12  [RFC5529][RFC]  -
>>  27 ENCR_CAMELLIA_CCM_16  [RFC5529][RFC]  -
>> 
>> where the RFCXXX would be this RFC.
> 
> Works for me.
> 
>> Check out the IANA considerations section and comment if there is
>> something you are not happy about.
> 
> Looks good. (the word "does" is a little weird but the RFC Editor can
> reword it)
> 
> I believe this document is ready for WGLC,
> 
> Paul
> 
> ___
> 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] IETF 96 IPsecME Agenda

[Tommy Pauly]

> On Jul 7, 2016, at 12:23 PM, Paul Wouters  wrote:
> 
> On Thu, 7 Jul 2016, Waltermire, David A. (Fed) wrote:
> 
 This leaves 25 minutes extra. Are there any additional topics to discuss?
>>> ESP? Yang? Others?
>> 
>> Are you or one of the other authors available to discuss these drafts? If 
>> so, how much time do you need?
>> 
>>> There is draft-pauly-ipsecme-split-dns and draft-mglt-ipsecme-rfc7321bis as
>>> well we could briefly talk about.
> 
> Yes. Tommy and I will be there and we can remind the WG about how useful
> our draft is for adoption, and I think Daniel is also there to talk
> about 7321bis which is pretty similar to 4307bis, but if he is not I
> can talk about it too.

I agree that we should have a short discussion around 
draft-pauly-ipsecme-split-dns, and I will be there to talk about it.

Thanks,
Tommy

> 
> Paul
> 
> ___
> 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] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

[Tommy Pauly]

I think we should definitely add a discussion around this to the Berlin agenda.

>From our end, we definitely want to see some measures to add quantum 
>resistance into IKEv2 to promote the adoption of IKEv2 over IKEv1 for clients 
>that are concerned. I think draft-fluhrer-qr-ikev2 provides a good starting 
>point for a WG document to do that. I agree that we can defer some of the 
>complexities around ID hiding to later solutions, in the interest of 
>simplicity and providing basic QR in the short term.

Thanks,
Tommy Pauly
Apple

> On Jul 4, 2016, at 9:40 AM, Paul Wouters <p...@nohats.ca> wrote:
> 
> On Mon, 4 Jul 2016, Scott Fluhrer (sfluhrer) wrote:
> 
>> Actually, the draft is a bolt-on to existing authentication methods;
> 
>> You might object "how is this different from a having a possibly global 
>> authentication key";
> 
>> Because of this, it wouldn't appear to be advisable to wait for the full 
>> solution; for people who are concerned about Quantum Computers, it would be 
>> appropriate to have a short term solution.  In my mind, it's OK if the short 
>> term solution doesn't address all possible scenarios; it's sufficient if it 
>> provides a way to address the immediate need for those people who are 
>> concerned.
> 
> In that case, I feel we are back at making a much simpler solution of
> providing a key identifier that leads to an additional mixing in of
> SKEYSEED generation. And not add methods of ID hiding. And have
> something that can be tested by implementations using a shared OTP.
> 
> If the people discussing this will be in Berlin, perhaps we should put
> this on the agenda to discuss?
> 
> Paul
> 
> ___
> 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] I-D Action: draft-ietf-ipsecme-tcp-encaps-00.txt

[Tommy Pauly]

Hello,

We've posted a new version of the TCP Encapsulation draft, now as a WG document 
(https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-00).

Here are the major changes in this version, based on the last round of feedback:
- Changed most references to IKEv2 to IKE to make this technique more generic
- Changed the Stream Prefix from IKEv2 to IKETCP
- Clarified the use of the Stream Prefix with regards to extra layers of 
protocols (TLS) in the appendix examples
- Clarified that ESP SPI must be zero

We'd like to post one more version with feedback and input from the group by 
our Berlin meeting. Please review!

Thanks,
Tommy

> On Jun 27, 2016, at 7:05 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the IP Security Maintenance and Extensions of 
> the IETF.
> 
>Title   : TCP Encapsulation of IKE and IPSec Packets
>    Authors : Tommy Pauly
>  Samy Touati
>  Ravi Mantha
>   Filename: draft-ietf-ipsecme-tcp-encaps-00.txt
>   Pages   : 19
>   Date: 2016-06-24
> 
> Abstract:
>   This document describes a method to transport IKE and IPSec packets
>   over a TCP connection for traversing network middleboxes that may
>   block IKE negotiation over UDP.  This method, referred to as TCP
>   encapsulation, involves sending all packets for tunnel establishment
>   as well as tunneled packets over a TCP connection.  This method is
>   intended to be used as a fallback option when IKE cannot be
>   negotiated over UDP.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> 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] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Tommy Pauly]

Here are my thoughts on the options for communicating the Implicit IV option in 
the proposal:

- A new transform type is problematic, as pointed out by Valery and Paul 
already, because it adds complexity to the proposal structure for configuring 
and parsing. This seems to be the least desirable option.

- The new transform ID is easy to add to implementations because it is just 
another value for an existing field. There is a slight downside in needing new 
ID allocations for what will be essentially a duplicate algorithm, but numbers 
are cheap. I think this is the easiest option to adopt and pass between 
implementation layers (userspace, kernel, etc), but once the layer doing 
encryption is using the value, it will probably want to flatten the information 
out into the original algorithm value and a flag that the IV is implicit.

- A new transform attribute is attractive as a clean protocol design, since it 
seems to be the type of information that transform attributes are meant to 
hold. There aren't many uses of transform attributes currently, so this may add 
work to protocol parsers. This may require passing the flag for implicit IVs 
separately throughout the implementation, rather than as part of the transform 
ID, but I would be willing to do this as an implementer for the sake of a 
cleaner protocol.

As such, I vote for either option 2 or 3: 2 for ease of implementation, 3 for 
clean protocol design.

Thanks,
Tommy

> On Jun 9, 2016, at 9:19 AM, Daniel Migault  
> wrote:
> 
> Hi,
> 
> Please find our new proposal with ESP using implicit IV [1]. We would like to 
> present and discuss it at the next IETF meeting.
> 
> We would be happy to have the WG opinion on which you think is the better way 
> to negotiate the implicit IV between two peers. The different options are 
> detailed in section 5 and copy paste here in the email:
> 
> """
>   Negotiation of the use of implicit IV can be done in 3 different
>   ways:
> 
>   o  An IMPLICIT IV Transform Type.  A proposal that contains this
>  transform type requires (if accepted) that IPsec use the implicit
>  IV and not include an explicit IV in the packets.  To facilitate
>  backward compatibility with non-supporting implementations the
>  Initiator SHOULD add another proposal that does not include this
>  transform type as well as cryptographic suite the Initiator does
>  not support the implicit IV.
> 
>   o  An IMPLICIT IV Transform ID.  This doubles the number of ENCR
>  transform IDs by creating an ENCR_AES_CCM_16_IIV for each
>  ENCR_AES_CCM_16.
> 
>   o  An IMPLICIT IV Transform Attribute, which would be associated to a
>  Transform Type ID, specifying the use of an implicit IV. marks a
>  particular ENCR transform as using implicit IVs.  To facilitate
>  backward compatibility with non-supporting implementations the
>  Initiator SHOULD add another ENCR transform for each algorithm so
>  marked.  In other words, for each ENCR_AES_CCM_16 with
>  keylength=256 and IIV=1, there will need to be an ENCR_AES_CCM_16
>  with keylength=256 and no IIV attribute.
> 
> """  
> 
> [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
> 
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
> Sent: Thursday, June 09, 2016 12:12 PM
> To: Tobias Guggemos; Yoav Nir; Daniel Migault
> Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt
> 
> 
> A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt
> has been successfully submitted by Daniel Migault and posted to the IETF 
> repository.
> 
> Name: draft-mglt-ipsecme-implicit-iv
> Revision: 00
> Title:Implicit IV for Counter-based Ciphers in IPsec
> Document date:2016-06-09
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/
> Htmlized:   https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00
> 
> 
> Abstract:
>   IPsec ESP sends an initialization vector (IV) or nonce in each
>   packet, adding 8 or 16 octets.  Some algorithms such as AES-GCM, AES-
>   CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not
>   require an unpredictable nonce.  When using such algorithms the
>   packet counter value can be used to generate a nonce, saving 8 octets
>   per packet.  This document describes how to do this.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec 

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

[Tommy Pauly]

Hi Valery,

Thanks for your reply! I think these are good points that we can clarify in 
future versions, although we can address these once it is a working group 
document. Responses inline.

Best,
Tommy

> On May 16, 2016, at 11:53 PM, Valery Smyslov  wrote:
> 
> Hi Tommy,
> 
> sorry for late reply. I'm mostly OK with the last version of the draft.
> 
> Few comments. It is a bit unclear how Stream Prefix is intended
> to be used with TLS. Is it insterted at the beginning of the TLS data stream?

The intention is that the prefix is used at the beginning of the stream even 
when TLS is being used (specifically, inside the encrypted TLS stream). Since 
the point of the prefix is to identify which specific protocol is being used, 
to differentiate from other TLS or VPN traffic, it is relevant to use it even 
when going over TLS port 443 in case the server being used also supports other 
VPN protocols over the same port using TLS. This is one of the points Yoav 
brought up.

> 
> Then, I think some text should be added describing a situation
> when the original responder having a valid (from its point of view)
> TCP session receives a request from original initiator for a new
> TCP session. This may happen if original initiator looses TCP
> state for some reason (RST from an attacker, temporary network failure etc.).
> In this case the responder will have two TCP sessions associated with
> the IKE SA. Clearly, the new one should be used for further communications,
> but only after it is proven to be authentic (some protected message is 
> received
> over it). But what the responder should do with the old TCP session?
> Keep it? Send FIN? Send RST? Just discard?
> 

In general, the approach of the draft is to clearly separate the TCP state from 
the IKE session state. If you look at Section 6, it specifically allows for 
multiple TCP connections between two peers even if there is only one IKE SA 
between them. If one of them becomes redundant (because the other peer opened 
up a new TCP flow for some reason), it would make sense to close the other in a 
usual way. I think this can be left to the implementation, but either a FIN or 
RST would be appropriate rather than a discard. We can add that to future 
versions.

> Regards,
> Valery.
> 
>> Hi Paul, Daniel,
>> 
>> Thanks for the comments! Responses inline.
>> 
>> I'd like to also hear feedback from people who brought up issues last time 
>> if possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP spec 
>> conformity, and Yoav regarding the magic value) to validate that this draft 
>> is satisfactory to resolve those issues.
>> 
>> Thanks,
>> Tommy
>> 
>> 
>>> On May 6, 2016, at 4:48 PM, Paul Wouters  wrote:
>>> 
>>> On Fri, 6 May 2016, Daniel Migault wrote:
>>> 
 s/IPSec/IPsec
>>> 
>>> If Tommy could also fix that auto-correct for my iphone, that would be
>>> great too :)
>>> 
 "This method is intended to be used as a fallback option when IKE
 cannot be negotiated over UDP."
 This seems to indicates that the method should only be used with IKEv2
 which contradicts the title. Thus I would mention. When used with IKE,
 this method...
>>> 
>>> This has happened in this group a few times now in different documents.
>>> People want to say IKEv2 to exclude IKE, but we should really say IKE
>>> so these documents don't look weird when/if we get IKEv3.
>> 
>> Sure, this can be changed to IKE rather than IKEv2. Whichever the group 
>> thinks makes most sense is fine with me.
>> 
>>> 
 I think that for interoperability, we should define a port at the
 IANA. If that port is 4500 we should detail why an how the two
 encapsulation method works. Are there any disadvantages of using an
 allocated port? One reason reason I suspect port agility may be needed
 is NAT. If so that should be clearly documented.
>>> 
>>> We should not define a port unless it is 443, which we kind of cannot.
>> 
>> Agreed. The most common port in practice will end up being 443; we do have 
>> 4500 allocated if people want to do generic TCP testing, but to get through 
>> NATs and firewalls, we need to often use 443 today. This may change in the 
>> future, so we specifically leave this port option as a configuration 
>> property.
>> 
>> We also specifically don't mention that the extra framing protocol will 
>> likely be TLS until we are in the appendix, due to comments from the group 
>> on inclusion of direct references to TLS in the standard.
>> 
>>> 
 I think that we shoudl specify that ESP SPI MUST be non zero to avoid
 the confusion between ESP SPI and Non-ESP marker.
>>> 
>>> First I thought this was not needed, because RFC-3948 would define that,
>>> but it does look confusing because it is mentioned in the section titled
>>> "UDP-Encapsulated ESP Header format":
>>> 
>>> https://tools.ietf.org/html/rfc3948#section-2.1
>>> 
>>> So the draft should probably include something simiar to that 

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

[Tommy Pauly]

Hi Paul, Daniel,

Thanks for the comments! Responses inline.

I'd like to also hear feedback from people who brought up issues last time if 
possible (Valery regarding inclusion of TLS, Tero regarding the 3GPP spec 
conformity, and Yoav regarding the magic value) to validate that this draft is 
satisfactory to resolve those issues.

Thanks,
Tommy


> On May 6, 2016, at 4:48 PM, Paul Wouters  wrote:
> 
> On Fri, 6 May 2016, Daniel Migault wrote:
> 
>> s/IPSec/IPsec
> 
> If Tommy could also fix that auto-correct for my iphone, that would be
> great too :)
> 
>> "This method is intended to be used as a fallback option when IKE
>> cannot be negotiated over UDP."
>> This seems to indicates that the method should only be used with IKEv2
>> which contradicts the title. Thus I would mention. When used with IKE,
>> this method...
> 
> This has happened in this group a few times now in different documents.
> People want to say IKEv2 to exclude IKE, but we should really say IKE
> so these documents don't look weird when/if we get IKEv3.

Sure, this can be changed to IKE rather than IKEv2. Whichever the group thinks 
makes most sense is fine with me.

> 
>> I think that for interoperability, we should define a port at the
>> IANA. If that port is 4500 we should detail why an how the two
>> encapsulation method works. Are there any disadvantages of using an
>> allocated port? One reason reason I suspect port agility may be needed
>> is NAT. If so that should be clearly documented.
> 
> We should not define a port unless it is 443, which we kind of cannot.

Agreed. The most common port in practice will end up being 443; we do have 4500 
allocated if people want to do generic TCP testing, but to get through NATs and 
firewalls, we need to often use 443 today. This may change in the future, so we 
specifically leave this port option as a configuration property.

We also specifically don't mention that the extra framing protocol will likely 
be TLS until we are in the appendix, due to comments from the group on 
inclusion of direct references to TLS in the standard.

> 
>> I think that we shoudl specify that ESP SPI MUST be non zero to avoid
>> the confusion between ESP SPI and Non-ESP marker. 
> 
> First I thought this was not needed, because RFC-3948 would define that,
> but it does look confusing because it is mentioned in the section titled
> "UDP-Encapsulated ESP Header format":
> 
> https://tools.ietf.org/html/rfc3948#section-2.1
> 
> So the draft should probably include something simiar to that section.

We can add a mention that the ESP SPI must be non-zero to match the other RFCs.

> 
>> An IANA allocated port could could be such indicaton. In that case,
>> would we need this prefix ?
> 
> We all know SSL VPNs exist because some networks block (4)500 on
> purpose.

That's correct.

> 
>> """
>> Any specific IKE SA, along with its Child SAs, is either TCP
>> encapsulated or not.  A mix of TCP and UDP encapsulation for a single
>> SA is not allowed.
>> """
> 
> Note: what it you suddenly notice you can go back to UDP. Wouldn't you
> have a mix while you migrate all the TCP-ESP to UDP-ESP?

We can make this section more clear. The main point it was trying to avoid was 
a technique used in previous drafts or protocols that used TCP for IKE in which 
only long packets would use TCP, and other would use UDP. The idea here is that 
all the IKE and ESP packets should share the same stream, and only switch 
potentially to use UDP if they do a MOBIKE switch. In that case, there could be 
packets on the wire that are mixed, but there would be a discrete break in 
message IDs.

> 
>> If I understand this correctly it means:
>> - a) IKEv2 SA using tcp encapsulation requires ESP to use TCP
>> encapsulation.
>> - b) an IKEv2 connection OR an ESP session cannot use TCP
>> encapsulation or UDP or no encapsulation.
>> I propose to have something similar to this:
>> When IKEv2 is using TCP encapsulation, the negotiated ESP SA MUST be
>> encapsulated with TCP.
> 
> It might be best to avoid making any statement on this. For example
> libreswan introduced a force-encaps= option to work around Amazon not
> routing ESP packets. If you mention anything for IKE vs ESP you might
> add limitations that might cause problems later on. While I think we
> should have SHOULD language on trying to move TCP sessions to UDP, I
> wouldn't go as far to forbid certain combinations.
> 
>> In fact a network may have different firewall rules for IKEv2 and ESP
>> """
>>  The original initiator (that is, the endpoint that initiated the TCP
>> connection and sent the first IKE_SA_INIT message) is responsible for
>> reestablishing the TCP connection if it is torn down for any
>> unexpected reason.  Since new TCP connections may use different ports
>> due to NAT mappings or local port allocations changing, the responder
>> MUST allow packets for existing SAs to be received from new source
>> ports.
>> """
>> Section 7:
>> This 

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-07.txt

[Tommy Pauly]

This version looks good to me! Seems ready for WGLC.

—Tommy

> On Apr 7, 2016, at 5:37 PM, Paul Wouters  wrote:
> 
> On Thu, 7 Apr 2016, internet-dra...@ietf.org wrote:
> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the IP Security Maintenance and Extensions of 
>> the IETF.
>> 
>>   Title   : Algorithm Implementation Requirements and Usage 
>> Guidance for IKEv2
> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-07
> 
> This update has two changes:
> 
> - Remove the MAY entries from the Recommendation of Authentication Method
>  table.
> - Change 256 bit key size for encryption from MAY to SHOULD.
> 
> It also seems to have some style changes, like re-introducing numbered
> tables, which were lost on the previous run. Perhaps Tero needs to
> update his xml2rfc tool :)
> 
> With these changes, I believe the document is ready for WGLC.
> 
> Paul
> 
> ___
> 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] Next steps on TCP Encapsulation for IKEv2

[Tommy Pauly]

Hi Yoav,

Thanks for the feedback. While I see the advantage of adding the magic value at 
the start of the non-TLS TCP stream, especially over port 443, this seems to 
require the document to even more explicitly discuss TLS. If implementations do 
end up using TLS, as I believe many will in practice, then presumably they 
would not include this magic byte at the beginning of their stream over TLS. 
This means that the inner protocol diverges depending on which set of protocols 
are being used for the stream. I would prefer that these be consistent if 
possible.

Thoughts?

Tommy

> On Apr 5, 2016, at 1:14 PM, Yoav Nir <ynir.i...@gmail.com> wrote:
> 
> Hi, Tommy.
> 
> The changes look fine, although I’m still not convinced we even need the TLS. 
> But that’s for another thread.
> 
> We foresee that most TCP encapsulation is likely to be in on port 443. I 
> think TCP encapsulation of IKEv2/IPsec should be easily distinguishable from 
> other types of traffic on the same port.
> 
> I propose we add a magic value at the start of a non-TLS TCP stream, 
> something very different from (0x16, 0x03, 0x01, 0x00).
> 
> Yoav
> 
> 
>> On 5 Apr 2016, at 12:27 PM, Tommy Pauly <tpa...@apple.com 
>> <mailto:tpa...@apple.com>> wrote:
>> 
>> Hello,
>> 
>> At our meeting yesterday, we agreed that we want one more revision of 
>> draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group 
>> adoption to clear up a few concerns.
>> 
>> Here are the changes we’re planning:
>> 
>> 1. Reconcile the length field size with 3GPP’s recommendation (sent out by 
>> Tero) to promote interoperability if any devices have already implemented 
>> 3GPP’s suggestions. This would mean changing the length field from 32 bits 
>> to 16 bits.
>> 
>> 2. Address the concerns around including too many direct references to use 
>> of TLS and port 443 in the body of the standards track document. The current 
>> plan here would be to make all direct references to TLS in the body of the 
>> document be more generic regarding any protocols over TCP that are added to 
>> encapsulate the IKE session, and point to an appendix that explains the 
>> caveats regarding TLS. The main point to communicate is that TLS should not 
>> influence the framing of IKE or ESP packets on the stream, and that the 
>> encryption and authentication properties of TLS do not influence the IKE 
>> session at all. Valery, I believe this should address your concerns.
>> 
>> Please reply with your feedback if you think these changes are good ideas, 
>> and if there are any other remaining points that should be changed before we 
>> move ahead.
>> 
>> After this, the plan would be to ask for working group adoption of the 
>> document if there are no other objections, and to in parallel start an 
>> informational document (perhaps a draft, perhaps outside of IETF) to 
>> describe the practical strategies for using TLS to encapsulate the tunnel, 
>> and more detail on proxy interactions.
>> 
>> Thanks,
>> Tommy Pauly
>> ___
>> IPsec mailing list
>> IPsec@ietf.org <mailto: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

[IPsec] Next steps on TCP Encapsulation for IKEv2

[Tommy Pauly]

Hello,

At our meeting yesterday, we agreed that we want one more revision of 
draft-pauly-ipsecme-tcp-encaps-03 before putting it up for working group 
adoption to clear up a few concerns.

Here are the changes we’re planning:

1. Reconcile the length field size with 3GPP’s recommendation (sent out by 
Tero) to promote interoperability if any devices have already implemented 
3GPP’s suggestions. This would mean changing the length field from 32 bits to 
16 bits.

2. Address the concerns around including too many direct references to use of 
TLS and port 443 in the body of the standards track document. The current plan 
here would be to make all direct references to TLS in the body of the document 
be more generic regarding any protocols over TCP that are added to encapsulate 
the IKE session, and point to an appendix that explains the caveats regarding 
TLS. The main point to communicate is that TLS should not influence the framing 
of IKE or ESP packets on the stream, and that the encryption and authentication 
properties of TLS do not influence the IKE session at all. Valery, I believe 
this should address your concerns.

Please reply with your feedback if you think these changes are good ideas, and 
if there are any other remaining points that should be changed before we move 
ahead.

After this, the plan would be to ask for working group adoption of the document 
if there are no other objections, and to in parallel start an informational 
document (perhaps a draft, perhaps outside of IETF) to describe the practical 
strategies for using TLS to encapsulate the tunnel, and more detail on proxy 
interactions.

Thanks,
Tommy Pauly___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New Version Notification for draft-tran-ipsecme-ikev2-yang-00.txt

[Tommy Pauly]

I agree that time intervals for IKE retransmits should be measured in 
milliseconds, not seconds.

Thanks,
Tommy

> On Mar 28, 2016, at 4:31 PM, Daniel Migault  
> wrote:
> 
> With the second as a unit. We cannot do it. However if we set it millisecond 
> we are fine. We also have a field that specify the policy. This field should 
> provide the policies of the different implementtation.  Such feed back is 
> definitely usefull for the next iteration of the draft.
> 
> BR
> Daniel
> 
> On Mar 28, 2016 18:06, "Paul Wouters"  > wrote:
> 
> 
> Sent from my iPhone
> 
> On Mar 28, 2016, at 16:43, Daniel Migault  > wrote:
> 
>> Hi Paul, 
>> 
>> I leave my co-authors to respond on the YANG aspects. 
>> 
>> Regarding the initial-retransmission-timeout I think we meant a time in 
>> second. Do you think we need more options?
> 
> Libreswan retransmits at 0.5 second and the doubling the interval up to 30 
> seconds. So 0.5, 1, 2, 4, 8, 16.
> 
> I don't think that you can put that in?
> 
> Note I didn't read all the options, there might be others too. I think to be 
> sure, you need to look at various implementations and see if it can work.
> 
> Paul
> 
>> BR, 
>> Daniel
>> 
>> On Mon, Mar 28, 2016 at 11:29 AM, Paul Wouters > > wrote:
>> On Sun, 27 Mar 2016, Daniel Migault wrote:
>> 
>> Subject: [IPsec] FW: New Version Notification for
>> draft-tran-ipsecme-ikev2-yang-00.txt
>> 
>> Please find our first version for the YANG model for IKEv2. Feel free
>> to post comments. I would be also happy to have face-to-face
>> discussions on the draft - especially from IKEv2 implementers.
>> 
>> Might be good for me to have a talk about it, especially because I'm
>> not a yang person. . I'm still a bit confused about the syntax. There is
>> code in the document that looks like "ready to use" but also looks like
>> "example to use". like:
>> 
>>   description
>>"This YANG module defines the configuration and operational
>> state data for Internet Key Exchange version 2 (IKEv2) on
>> IETF draft.
>> Copyright (c) 2016 Ericsson AB.
>> All rights reserved.";
>> 
>> All rights reserved? huh? Is that an example? or is this an error?
>> 
>> I'm confused about units too, like:
>> 
>>   leaf initial-retransmission-timeout {
>>type uint32;
>>description
>>  "initial retransmission timeout value";
>>  }
>> 
>> look weird to me. What's the unit here? uint32 is not a unit, it is
>> a number Is this seconds? miliseconds? seconds since 1970? Since 1772?
>> 
>> Some of it looks like just copying IANA registries? So that would be
>> outdated quickly. How would that get updated? Should we really put
>> chunks of code in RFCs like that?
>> 
>> Paul
>> 
>> 
>> ___
>> 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 
> 
> 
> ___
> 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] New version of IKEv2 TCP Encapsulation draft

[Tommy Pauly]

el. Depending on 
how IPSec over TCP is implemented on the server end, the ESP packets could 
eventually be sent over UDP before being decrypted (specifically, if the TCP 
connection is terminated at a device before the IKE endpoint). As such, we want 
to make sure that there are not very large (such as 64K bytes) IKE and ESP 
messages being sent on a tunnel that may have to then fragmenting the ESP 
datagrams before decrypting them.

>  
> 3. Section 4.
>  
>Any specific IKE SA, along with its Child SAs, is either TCP
>encapsulated or not.  A mix of TCP and UDP encapsulation for a single
>SA is not allowed.  The exception to this rule is SAs that are
>migrated between addresses using MOBIKE Section 7.
>  
> the last sentence is not accurate. As far as I understand, if IKE SA 
> (along with 
> its Child SAs) migrated from one address to another via MOBIKE, then 
> either all these SAs (IKE & its children) use TCP encapsulation
> or all them use traditional encapsulation. So, it is not an exception
> from the rule. Well, my reading of the rule that "the mix is not allowed"
> is that by "mix" you mean situation when IKE SA uses one type
> of encapsulation while some of its children use different type.
> I'd suggest to clarify this text so that any ambiguity is eliminated.

You are correct that there is not a case in which there is a mix between IKE 
and Child SAs. We will clarify this in the next version.

> 
> 4. Section 5.
>  
>A peer must discard a partially received message due to a broken
>connection.
>  
> s/must/MUST ?

I think we can make this a MUST.

>  
> 5. Section 9.
>  
> NAT keep-alive packets over a TCP
>encapsulated IPSec connection will be sent with a length value of 1
>byte, whose value is 0xFF Figure 2.
>  
> Shouldn't "Figure 2" be enclosed in brackets?

Agreed, this can be in brackets.

>  
> 6. Section 11.
>  
> There is no subsection describing additional overhead to the size of the 
> ESP 
> and IKE messages when using TCP encapsulation.
> This overhead may be important for some implementations. Consider some
> application (e.g. VoIP) that sends small packets, e.g. about 50 bytes in 
> size.
> With UDP encapsulation the overhead is 8 (ESP) + 8 (UDP) + 20 (IP) = 36 
> bytes.
> With TCP encapsulation it is 8 (ESP) + 4 (len) + 20 (TCP) + 20 (IP) = 52 
> bytes.
> The difference may be significant for low bandwith networks or low power 
> consumption
> devices. With TLS the situation will be worse.

This calculation does not work exactly, since TCP is a stream and the IKE/ESP 
payloads will not correspond directly with TLS frames or TCP segments. We can 
mention the overhead in general, but it is not a deterministic factor.

>  
> 7. Section 11.3
> 
> It is not clear from the text where NULL cipher should be used - in ESP
> or in TLS? If it is about TLS, then does by NULL cipher you mean
> TLS_NULL_WITH_NULL_NULL or something else? Is it MTI in TLS 
> (I'm not a TLS expert)? If it is about ESP NULL cipher, 
> then it contradicts to last para in Section 12... I think it should be 
> clarified.

This should refer to the TLS NULL cipher, not ESP.

>  
> 8. The draft is silent about ESP Sequence Numbers. I think a few words could 
> be added that while the ESP SN are unnecessary with TCP encapsulation,
> the sender still must increnet it in every sent packet.

Okay, we can add a comment for that.

>  
> Regards,
> Valery Smyslov.
> 
>  
>  
>  
>> - Original Message - 
>> From: Tommy Pauly <mailto:tpa...@apple.com>
>> To: ipsec@ietf.org <mailto:ipsec@ietf.org>
>> Sent: Tuesday, February 16, 2016 12:52 AM
>> Subject: [IPsec] New version of IKEv2 TCP Encapsulation draft
>> 
>> Hello all,
>> 
>> I’ve just posted a new version of the IKEv2 and IPSec TCP Encapsulation 
>> draft. The changes include:
>> 
>> - Making the use case (as a last resort if UDP is blocked) more clear in the 
>> introduction
>> - Clarify connection establishment and teardown section (allowing a resumed 
>> connection to start with either IKE or ESP traffic, allowing multiple SAs on 
>> one TCP connection)
>> - Adding more details about interactions with IKEv2 fragmentation, and TCP 
>> MSS and QoS markings
>> - Clarifying the keep-alive/DPD section
>> - A new appendix written by a new author from Cisco giving four example 
>> exchanges with TCP encapsulation of IKEv2.
>> 
>> https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt 
>> <https://tools.ietf.org/id/draft-pa

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

[Tommy Pauly]

> On Mar 5, 2016, at 5:11 AM, Valery Smyslov  wrote:
> 
>> If there is no consensus about puzzles, perhaps we should leave that
>> part out of the document?
> 
> I had an impression that threre was a consensus when
> the document was adopted by WG. In any case, I think that it is better to 
> have an interoperable specification than to leave puzzles at all (and thus 
> make them a subject
> for a proprietary solutions).

I agree that interoperability is key, and having a definition is useful if 
anyone will be implementing it. 

> 
>>> And note, that the way puzzles are used in the draft makes every
>>> attempt to not discriminate those initiators that don't support puzzles
>>> or cannot afford enough power to solve them. In other words -
>>> puzzles mechanism in the draft is not an absolute barrier for
>>> unsupported clients, it is just a first-class ticket for those who support 
>>> and afford.
>> 
>> which is the botnet more than mobile phones. Which is why I don't see I
>> would implement this. It seems session resumption would be more
>> effective at distinguishing returning clients from a botnet.
> 
> Sure. But before every client becomes a "returning" one it must pass usual 
> IKE_SA_INIT. And it cannot be a returning client the rest of its
> life - it must be fully reauthenticated from time to time.
> Thus the resumption cannot make the task of DDoS protection in IKE_SA_INIT 
> non-existent.

Going along with Paul’s point, it does seem that the approach of session 
resumption would favor the legitimate mobile-device client, where the puzzle 
approach may unintentionally favor the botnets themselves. But it is also a 
good point that session resumption alone cannot solve the DDoS problem.

Would it be possible, I wonder, to try to combine these approaches to create a 
solution that has the responder-protecting properties of puzzles, while still 
favoring legitimate clients? This would require using some property of 
legitimate clients (who will be able to successfully authenticate later in the 
negotiation) as part of the puzzle-challenge, or a way to skew the results in 
their favor. I’m not sure if this is possible from the algorithmic perspective, 
but it would be interesting to use some pre-known value (a shared secret, an 
initiator or responder ID, etc) as a key to the puzzle that, if known, would 
allow a quicker solution. It should be impossible to tell what this original 
key or salt is from an eavesdropper’s perspective, but it could make the 
calculation quicker for a client with a weak processor that was correctly 
provisioned to communicate with the server.

Thanks,
Tommy

> 
>>> Could you, please, elaborate what scenario do you have in mind?
>> 
>> If you have an IPsec server willing to talk IKE/IPsec to anonymous
>> clients. So one-side AUTH_NULL, the other a real authentication. Since
>> the server talks to everyone who sends it an IKE_INIT, 
> 
> How it is concerned with AUTH_NULL? In IKE_SA_INIT the responder
> doesn't yet know that the initiator will use NULL auth or real auth, so any 
> server usually replies to everyone who sends IKE_SA_INIT request.
> 
>> it is important
>> that this IKE_INIT reply is much smaller than the IKE_INIT request,
>> so this does not become a new amplification target. 
> 
> IKE_SA_INIT reply in most cases is smaller than request.
> The responder returns only a subset of initiator's SA transforms, a subset of 
> initiator's  notifications (returning only supported ones),
> and usually only a subset of VIDs.
> In which real life scenario it is larger than request?
> 
>> Currently, such
>> a server could only always require dcookies to accomplish this, but
>> that takes an additional round trip. Some kind of padding in the
>> IKE_INIT request could easilly prevent this.
> 
> Sorry, I failed to understand how additional padding would work.
> Are you going to reject initiators that don't include this additional padding
> (i.e. - all usual IKEv2 clients)? Am I missing something?
> 
> Regards,
> Valery.
> 
>> Paul
> 
> ___
> 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] WGLC on draft-ietf-ipsecme-ddos-protection-04

[Tommy Pauly]

Hi Valery,

Responses inline.

Thanks!
Tommy

> On Mar 5, 2016, at 2:00 AM, Valery Smyslov  wrote:
> 
> Hi Tommy,
> 
> thank you for your comments.
> 
 I tend to agree with Paul that I find it unlikely, from an implementor’s 
 standpoint, that many Initiators will choose
 to implement the puzzle logic, especially ones that are running on mobile 
 devices. It is unlikely that the phones will be able
 to solve the puzzles quickly enough to beat out botnets, and it would be 
 hard to justify the battery consumption necessary.
 That being said, the document does a very good job of explaining the 
 problem space, and the other parts of its solution
 (rate-limiting and suggesting session resumption) make good sense. Perhaps 
 there can be more focus on how a responder
 can best protect itself if indeed the majority of its clients do not 
 support puzzles?
> 
> Sections 4 - 6 describe measures other than puzzles that the responder can 
> use to defend itself against DDoS attack.
> Do you think it is not enough? Puzzles are a new thing, that's why more text 
> is needed to explain how they are fit
> into the protocol. However the draft is not solely about puzzles, and I think 
> it covers other defending techniques in sufficient details.

Perhaps it would be useful to rearrange the sections to highlight this more 
clearly. The first section about a solution is Puzzles (section 3), followed by 
sections 4-6 which cover other aspects of DDoS avoidance strategies, which is 
then followed by an in-depth explanation of the Puzzles in the protocol 
(sections 7-9). Since the other aspects and sandwiched in between sections 
purely focused on puzzles, the draft really feels like it is about puzzles. 
What if the other approaches were moved before the first puzzles section, so 
the entire section on puzzles can be contiguous?

> 
 One question on section 7.1.2:
 
 If the received message contains a PUZZLE notification and doesn't
 contain a COOKIE notification, then this message is malformed because
 it requests to solve the puzzle, but doesn't provide enough
 information to do it.  In this case the Initiator SHOULD resend
 IKE_SA_INIT request.  If this situation repeats several times, then
 it means that something is wrong and the IKE SA cannot be
 established.
 
 I am concerned that the suggestion for the initiator reacting to malformed 
 IKE_SA_INIT packets is to send more traffic to the responder.
 The responder should not legitimately send a PUZZLE notification without a 
 COOKIE notification, since this would be invalid.
 If the initiator sees this, it can either assume that (a) the responder’s 
 implementation is out of spec, or (b) some malicious third party
 is deliberately modifying the unencrypted packet. In the first case, 
 trying to send the IKE_SA_INIT again would be in vain;
 in the second case, we have provided a way for a third party to cause 
 initiators to send more traffic to the responder,
 thus providing an attack vector. What are your thoughts on this?
 
>>> A proper responder would not send a malformed packet. An attacker could 
>>> send a malformed response immediately
>>> after the initiator sends the request. By the time the initiator gets the 
>>> real responder’s response, it has lost state.
>>> 
>>> That is why it is always a good idea (not just in this context) for the 
>>> initiator to ignore malformed responses until the timeout is reached.
>>> 
>> That makes sense. The wording, however, could imply that the Initiator 
>> should resend the request as if in response to the malformed packet.
>> Based on your comment, the Initiator should wait for the usual amount of 
>> time before retrying, rather than immediately retrying the packet.
>> It may be useful to clarify this in the text.
> 
> You are right that the Initiator should wait for the retransission timer to 
> expire before resending message.
> I agree that the wording is ambiguous about that. How about the following?
> 
>  If the received message contains a PUZZLE notification and doesn't
>  contain a COOKIE notification, then this message is malformed because
>  it requests to solve the puzzle, but doesn't provide enough
>  information to do it.  In this case the Initiator MUST ignore
>  the received message and continue to wait until either the valid one
>  is received or the retransmission timer fires. If it fails to receive the 
> valid
>  message after several retransmissions of IKE_SA_INIT request, then
>  it means that something is wrong and the IKE SA cannot be established.

I think that is more clear, thanks!
> 
> Regards,
> Valery.
> 
>> Thanks,
>> Tommy
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org

Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

[Tommy Pauly]

> On Mar 4, 2016, at 9:32 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
> 
>> 
>> On 4 Mar 2016, at 7:02 PM, Tommy Pauly <tpa...@apple.com> wrote:
>> 
>> Hello Dave,
>> 
>> I tend to agree with Paul that I find it unlikely, from an implementor’s 
>> standpoint, that many Initiators will choose to implement the puzzle logic, 
>> especially ones that are running on mobile devices. It is unlikely that the 
>> phones will be able to solve the puzzles quickly enough to beat out botnets, 
>> and it would be hard to justify the battery consumption necessary. That 
>> being said, the document does a very good job of explaining the problem 
>> space, and the other parts of its solution (rate-limiting and suggesting 
>> session resumption) make good sense. Perhaps there can be more focus on how 
>> a responder can best protect itself if indeed the majority of its clients do 
>> not support puzzles?
>> 
>> One question on section 7.1.2:
>> 
>> If the received message contains a PUZZLE notification and doesn't
>>  contain a COOKIE notification, then this message is malformed because
>>  it requests to solve the puzzle, but doesn't provide enough
>>  information to do it.  In this case the Initiator SHOULD resend
>>  IKE_SA_INIT request.  If this situation repeats several times, then
>>  it means that something is wrong and the IKE SA cannot be
>>  established.
>> 
>> I am concerned that the suggestion for the initiator reacting to malformed 
>> IKE_SA_INIT packets is to send more traffic to the responder. The responder 
>> should not legitimately send a PUZZLE notification without a COOKIE 
>> notification, since this would be invalid. If the initiator sees this, it 
>> can either assume that (a) the responder’s implementation is out of spec, or 
>> (b) some malicious third party is deliberately modifying the unencrypted 
>> packet. In the first case, trying to send the IKE_SA_INIT again would be in 
>> vain; in the second case, we have provided a way for a third party to cause 
>> initiators to send more traffic to the responder, thus providing an attack 
>> vector. What are your thoughts on this?
> 
> A proper responder would not send a malformed packet. An attacker could send 
> a malformed response immediately after the initiator sends the request. By 
> the time the initiator gets the real responder’s response, it has lost state. 
> 
> That is why it is always a good idea (not just in this context) for the 
> initiator to ignore malformed responses until the timeout is reached.

That makes sense. The wording, however, could imply that the Initiator should 
resend the request as if in response to the malformed packet. Based on your 
comment, the Initiator should wait for the usual amount of time before 
retrying, rather than immediately retrying the packet. It may be useful to 
clarify this in the text.

Thanks,
Tommy

> 
> Yoav

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

Re: [IPsec] Proposed wording for a revised charter

[Tommy Pauly]

I would also like to see the draft for TCP encapsulation added as an item, 
since we’ve gotten a fair amount of support for it. For the purposes of the 
charter, it may be good to have a broader explanation of the goal—something to 
the effect that the working group should focus on making sure that IKEv2 can be 
deployed more universally by taking into account limitations of various 
networks. Previous RFCs like IKE fragmentation have contributed to this; TCP 
encapsulation tries to solve another set of problematic networks; and we can 
imagine that there may be more to investigate, such as taking into account the 
limitations and requirements of IoT networks, etc.

Tommy

> On Mar 1, 2016, at 12:32 PM, Paul Wouters  wrote:
> 
> S/mostly// 
> 
> Add IKE over tcp and DNS extensions for ikev2?
> 
> Sent from my iPhone
> 
>> On Mar 1, 2016, at 11:18, Paul Hoffman  wrote:
>> 
>> Greetings. We need to update our charter to reflect our current and expected 
>> work. Dave and I propose the following text. Please let us know within the 
>> next week if you have suggestions for changes.
>> 
>> --Paul Hoffman and Dave Waltermire
>> 
>> 
>> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs),
>> IKEv2 (RFC 7296), and the IPsec security architecture (RFC 4301). IPsec is
>> widely deployed in VPN gateways, VPN remote access clients, and as a
>> substrate for host-to-host, host-to-network, and network-to-network
>> security.
>> 
>> The IPsec Maintenance and Extensions Working Group continues the work of
>> the earlier IPsec Working Group which was concluded in 2005. Its purpose is
>> to maintain the IPsec standard and to facilitate discussion of 
>> clarifications,
>> improvements, and extensions to IPsec, mostly to IKEv2.
>> The working group also serves as a focus point for other IETF Working Groups
>> who use IPsec in their own protocols.
>> 
>> The current work items include:
>> 
>> IKEv2 contains the cookie mechanism to protect against denial of service
>> attacks. However this mechanism cannot protect an IKE end-point (typically,
>> a large gateway) from "distributed denial of service", a coordinated attack 
>> by
>> a large number of "bots". The working group will analyze the problem and
>> propose a solution, by offering best practices and potentially by extending
>> the protocol.
>> 
>> IKEv2 utilizes a number of cryptographic algorithms in order to provide
>> security services. To support interoperability a number of mandatory-to-
>> implement (MTI) algorithms are defined in RFC4307. There is interest in
>> updating the MTIs in
>> RFC4307 based on new algorithms, changes to the understood security
>> strength of existing algorithms, and the degree of adoption of previously
>> introduced algorithms. The group will revise RFC4307 proposing updates to
>> the MIT algorithms used by IKEv2 to address these changes.
>> 
>> There is interest in supporting Curve25519 and Curve448 for ephemeral key
>> exchange in the IKEv2 protocol. The group will extend the
>> IKEv2 protocol to support key agreement using these curves and their
>> related functions.
>> 
>> This charter will expire in August 2016. If the charter is not updated before
>> that time, the WG will be closed and any remaining documents revert back to
>> individual Internet-Drafts.
>> 
>> 
>> 
>> 
>> ___
>> 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] WGLC on draft-ietf-ipsecme-ddos-protection-04

[Tommy Pauly]

Hello Dave,

I tend to agree with Paul that I find it unlikely, from an implementor’s 
standpoint, that many Initiators will choose to implement the puzzle logic, 
especially ones that are running on mobile devices. It is unlikely that the 
phones will be able to solve the puzzles quickly enough to beat out botnets, 
and it would be hard to justify the battery consumption necessary. That being 
said, the document does a very good job of explaining the problem space, and 
the other parts of its solution (rate-limiting and suggesting session 
resumption) make good sense. Perhaps there can be more focus on how a responder 
can best protect itself if indeed the majority of its clients do not support 
puzzles?

One question on section 7.1.2:

If the received message contains a PUZZLE notification and doesn't
   contain a COOKIE notification, then this message is malformed because
   it requests to solve the puzzle, but doesn't provide enough
   information to do it.  In this case the Initiator SHOULD resend
   IKE_SA_INIT request.  If this situation repeats several times, then
   it means that something is wrong and the IKE SA cannot be
   established.

I am concerned that the suggestion for the initiator reacting to malformed 
IKE_SA_INIT packets is to send more traffic to the responder. The responder 
should not legitimately send a PUZZLE notification without a COOKIE 
notification, since this would be invalid. If the initiator sees this, it can 
either assume that (a) the responder’s implementation is out of spec, or (b) 
some malicious third party is deliberately modifying the unencrypted packet. In 
the first case, trying to send the IKE_SA_INIT again would be in vain; in the 
second case, we have provided a way for a third party to cause initiators to 
send more traffic to the responder, thus providing an attack vector. What are 
your thoughts on this?

Thanks,
Tommy


> On Mar 4, 2016, at 7:29 AM, Paul Wouters  wrote:
> 
>> On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) 
>>  wrote:
>>  All:
>> 
>>  With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I 
>> believe the draft is shaping up nicely,
>>  but needs additional review. To that end, this message starts a Working 
>> Group Last Call (WGLC) for
>>  draft-ietf-ipsecme-ddos-protection-04.
>> 
>>  The version to be reviewed is 
>> https://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt.
>> 
>>  Please send your comments, questions, and edit proposals to the WG mail 
>> list until March 18, 2015.  If you
>>  believe that the document is ready to be submitted to the IESG for 
>> consideration as a Standards Track RFC
>>  please send a short message stating this.
> 
> I think the document is well written with respect to DDOS. I like
> everything except the puzzles. It seems a lot of complexity for
> no gain, especially with the problem being that botnets are better
> at puzzle solving then mobile phones who want to not drain their
> batteries. I would prefer this document to proceed without the
> puzzles, but I won't object to it if it remains in the document.
> As an implementor, it would be extremely unlikely that I would
> implement puzzles.
> 
> Recently, I also thought about amplification attacks, which is not
> covered by the document. For instance, legitimate clients could pad
> their IKE_INIT Request as a way to tell the responder they are not just
> using the responder to amplify a DDOS attack. I am thinking of making
> that the default for some Opportunistic IPsec so it cannot be abused for
> amplification. I'd like to see that added to the draft if possible. Or
> if this document would not proceed, I would be tempted to write a draft
> for this idea.
> 
> Paul
> 
> ___
> 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] New version of IKEv2 TCP Encapsulation draft

[Tommy Pauly]

Hello all,

I’ve just posted a new version of the IKEv2 and IPSec TCP Encapsulation draft. 
The changes include:

- Making the use case (as a last resort if UDP is blocked) more clear in the 
introduction
- Clarify connection establishment and teardown section (allowing a resumed 
connection to start with either IKE or ESP traffic, allowing multiple SAs on 
one TCP connection)
- Adding more details about interactions with IKEv2 fragmentation, and TCP MSS 
and QoS markings
- Clarifying the keep-alive/DPD section
- A new appendix written by a new author from Cisco giving four example 
exchanges with TCP encapsulation of IKEv2.

https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt 

https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03 


I believe this should address many of the comments the last draft received. 
Please take a look and provide your feedback! If the working group is in favor, 
I’d like to see if this can be adopted by the working group.

Thanks,
Tommy

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

Re: [IPsec] meeting at IETF-95 ?

[Tommy Pauly]

+1 to having a meeting at IETF 95.

Thanks,
Tommy

> On Jan 12, 2016, at 6:56 AM, Paul Wouters  wrote:
> 
> 
> I hope we are scheduling a meeting for IETF-95. Last time we did not
> meet and ended up meeting in the hallway. This time there are more
> drafts being suggested and worked on.
> 
> Paul
> 
> ___
> 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] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt

[Tommy Pauly]

> On Jan 11, 2016, at 8:19 AM, Tero Kivinen  wrote:
> 
> Yoav Nir writes:
>> Second, as I understand it, those battery-powered devices tend to
>> use 802.15.4 networks with 127-byte frames. There’s 6LoWPAN to
>> provide fragmentation support, but that’s similar to using IKE’s
>> fragmentation for the same issue. Can anything be done at all with
>> 127-byte frames, that include the (IPv6?) headers, the 8-byte UDP
>> header, the 20-byte IKEv2 header in addition to all the payload
>> headers? If we need fragmentation anyway, I don’t know if
>> compression matters. 
> 
> 802.15.4 networks also have 802.15.9, which will provide its own
> fragmentation and reassembly for the IKEv2 frames (not including IP or
> UDP headers, as those are not used, this is raw IKEv2 frames over raw
> 802.15.4 frames).
> 
> In those environments the IKEv2 is used to negotiate link keys between
> two devices. The payloads are already quite compacted, i.e. there will
> not be several proposals for ciphers, only one, and all extra payloads
> are omitted anyways. 

Tero’s comments seem to confirm the idea that constrained devices will 
generally be using a small set of proposals, and thus do not need compression. 

The document referred to in the draft as IPSEC-IOT-REQS, 
draft-mglt-6lo-diet-esp-requirements-01, recommends essentially one algorithm 
for the Child SA algorithm (AES-CCM), so it may be safe to assume that IoT 
devices could converge to a small set of IKE SA algorithms to standardly use. 
And, while this document does recommend compression for ESP packets, I can see 
more of an argument being made for compressing ESP traffic (which may be many 
packets) than for compressing the IKE_SA_INIT packet, which is already a 
one-time-cost small packet.

Valery, do you have specific real-world examples of IKE_SA_INIT packets that 
are being used by IoT devices that get a benefit from this compression? Without 
this, it seems that adding compression to IKE would add a fair amount of 
complexity to optimize a packet that is already fairly inexpensive to send.

Thanks,
Tommy

> -- 
> 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] TCP Encapsulation draft

[Tommy Pauly]

> On Dec 14, 2015, at 6:46 AM, Valery Smyslov  wrote:
> 
> Hi,

Hi Valery,

Thanks for your comments! Responses inline.
> 
> I have some comments on the TCP Encapsulation draft.
> 
> 1. The draft assumes that using TCP encapsulation is always pre-configured,
>   i.e. for each peer there is a configuration option with two possible values 
> -either "use traditional UDP transport" or "use TCP (TLS) transport".
>   I think that this is inflexible since network topology can change over time
>   as well as middleboxes' capabilities. Since TCP encapsulation isa "last 
> resort" with a lot of drawbacks, I'd rather make it use only whenit is 
> really needed. Granted the use of TCP encapsulation
>   cannot be negotiated, however the case when it is needed can be detected.
>   So, I suggest to add the third option - "try first UDP transport and fall 
> back
>   to TCP (TLS) encapsulation if no response was received". Note, that this 
> behaviour
>   is already defined in the draft when peer's addresses are changed via 
> MOBIKE,I just suggest to make it available from the beginning of SA 
> establishment.

The idea of using TCP as the fallback from UDP is exactly what the entire draft 
is about. The preconfiguration is not whether to always use TCP, but whether to 
use TCP once UDP fails, and upon which port. Since the entire idea of using TCP 
is predicated on the idea that UDP was already blocked on a previous attempt, 
this must be preconfigured.

TCP is only used when UDP fails:
"If both of the other two methods are not
 available or appropriate, both IKEv2 negotiation packets as
 well as ESP packets can be sent over a single TCP connection to
 the peer."

As it says in the configuration section, UDP is the preferred transport: 

"Since TCP encapsulation of IKEv2 and IPSec packets adds overhead and
   has potential performance trade-offs compared to direct or UDP-
   encapsulated tunnels (as described in Performance Considerations, Section 
7), 
implementations SHOULD prefer IKEv2 negotiation over UDP.”

We can make it more explicit that UDP should be tried first, but that is 
certainly the intent.


> 2. Please, emphasize that TCP encapsulation cannot replace traditional
>   transport, otherwise we can run into interoperability problem.Something 
> along the lines:
> 
>   Those implementations that support TCP encapsulation MUST still support 
>traditional transport, defined in [RFC7296] for IKE and in [RFC4303] 
> and
>   [RFC3948] for ESP.

Sure, although I think clarifying (1) that UDP is always tried first should 
cover this as well.

> 
> 3. The following text in Section 3 is unclear to me:
> 
>  Although a TCP stream may be able to send very long messages,
>  implementations SHOULD limit message lengths to typical UDP datagram
>  ESP payload lengths.  
>   I wonder what is a "typical UDP datagram ESP payload lengths"?
>   How implementation could limit upper-level's message length? 

Based on discussion on the list, we decided not to specify a specific value. 
The point is to not send very large messages in the TCP stream, since they will 
often be sent back into a traditional unix networking kernel once decrypted. 
The message length can be simply limited by setting the MTU to a normal value 
on the virtual interface being used for the VPN.

> 4. The draft is silent about AH. I presume AH cannot be used withTCP 
> encapsulation (as it cannot be used with UDP encapsulation),
>   however I think it must be spelled out.

Okay, we can say this only applies to ESP, not AH.
> 
> 5. For the following text:
> 
>  An unexpected FIN or a RST on the TCP connection may indicate either
>  a loss of connectivity, an attack, or some other error. ... The original
>  initiator (that is, the endpoint that initiated the TCP connection
>  and sent the first IKE_SA_INIT message) is responsible for re-
>  establishing the TCP connection if it is torn down for any unexpected
>  reason. 
>   I think this is not enough. Consider the situation when attacker manages to
>   send RST to only one peer, say it be the original responder. In this case
>   the states of the peers become de-syncronized: while the original responder
>   tearns down its TCP session, the original initiator thinks it is up.
>   If the original responder has some data to be sent while the original
> initiator has no such data, then we have some kind of deadlock.
>   It seems that the original initiator must send keepalive messages
>   with a pretty high frequency whenever it becomes idle.

RST attacks are inherent to TCP. What do you propose on top of this? I don’t 
think we want to recommend for more frequent keepalives, necessarily. Note that 
any time the client will try to send any traffic (this is any ESP traffic, so 
it will probably be fairly quickly), the connection will get a RST if the 
server thinks the port is no longer 

Re: [IPsec] New revision of TCP Encapsulation draft

[Tommy Pauly]

Hi Yaron,

The original version of the draft did not require that the new TCP connection 
begin with an IKE message, but it was added in response to feedback we received 
at our meeting in Yokohama.

The concern was that the new TCP connection would almost certainly have 
different ports from the old connection. In order for the server to send 
packets back to the client, it needs to know the correct mapping for both the 
IKE SAs and the Child SAs. If we allow an ESP packet to be the first packet of 
a new connection, it may be hard to implement a correct server that reacts to 
that and adjusts all associated IKE and Child SA values to use the new port. 
However, it the first packet is an IKE packet, the server can essentially treat 
it as if it were MOBIKE and reset the ports.

In the case of multiple IKE SAs over a TCP connection (which is a new edge case 
that has been brought up), perhaps it would make sense to say that for all IKE 
SAs using the connection, at least one IKE message must precede any ESP 
messages for a Child SA of the IKE SA.

Does this make sense?

Thanks,
Tommy

> On Dec 8, 2015, at 2:12 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
> 
> Hi Samy,
> 
> Thanks for the new draft. It addresses most of my comments, but one question 
> remains.
> 
> I still don't understand why we require that each connection should start 
> with an IKE message. The explanation given is "to allow the peer to know with 
> which IKE session the traffic is associated." But of course the ESP SPI 
> identifies the Child SA, and implicitly, the IKE SA.
> 
> Moreover, later in the same section you allow multiple IKE SAs over the same 
> connection, which again doesn't work well with the reasoning above.
> 
> Best,
> Yaron
> 
> On 12/08/2015 08:40 AM, Samy Touati wrote:
>> Hi Yaron and Yoav,
>> 
>> An updated draft addressing your comments has been posted.
>> 
>> https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt 
>> <https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt>
>> 
>> Please check it out, and provide feedback.
>> 
>> 
>> Thanks.
>> Samy.
>> 
>> 
>> From: Yaron Sheffer < <mailto:yaronf.i...@gmail.com>yaronf.i...@gmail.com 
>> <mailto:yaronf.i...@gmail.com>>
>> Sent: Nov 20, 2015 3:11 PM
>> To: Tommy Pauly; IPsecME WG
>> Subject: Re: [IPsec] New revision of TCP Encapsulation draft
>> 
>> Hi Tommy,
>> 
>> I also think this is very relevant work. Here are some comments to -01:
>> 
>> I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited 
>> under "prior work", both because it is documented and also because I 
>> believe it is implemented by a vendor.
>> 
>> In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers 
>> will use UDP encapsulation even when there is no NAT on the path, for 
>> example because networks or middleboxes do not support IP protocols 
>> other than TCP and UDP."
>> 
>> "Although a stream" - this paragraph is not worded very well (streams 
>> don't send anything) and is hard to understand. There are lots of 
>> networks that use jumbo frames and so hardcoding the value 1500 into the 
>> spec may not be a good idea.
>> 
>> I can think of HA cases where several gateways are handling ESP SAs that 
>> are all associated with the same IKE SA. So I'm wondering why we are 
>> insisting on all Child SAs being in the same connection, and as a result 
>> requiring that an IKE message be the preamble to any new connection.
>> 
>> Although it might seem obvious, I think Sec. 3 should say explicitly 
>> that if the connection is closed midway through a message, the recipient 
>> must silently drop the partial message.
>> 
>> You may want to add to the last paragraph of the Security 
>> Considerations: This document explicitly does not define a profile for 
>> TLS when used in this manner, or any relation between identities at the 
>> IPsec level and those at the TLS level ("channel binding").
>> 
>> Thanks,
>> Yaron
>> 
>> On 11/20/2015 11:49 PM, Tommy Pauly wrote:
>> > Hello,
>> >
>> > Based on the feedback received at our informal meeting in Yokohama, I’ve 
>> > updated the draft for TCP Encapsulation of IKEv2 and ESP:
>> >
>> > https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01 
>> > <https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01>
>> >
>> > The revisions include:
>> > - More explanation in the introduction about the

Re: [IPsec] RFC 4307bis

[Tommy Pauly]

Hi Daniel,

Thanks for making these changes! I think this makes the document much clearer.

With regards to the Introduction, it may be beneficial at this point to have 
subsections of the introduction to make it easier to parse. Right now there 
seem to be several topics that don’t necessarily flow into one another: 
explaining mandatory-to-implement algorithms, explaining which version of IKE 
is relevant, explaining deprecation of algorithms, and the IoT section.

Thanks,
tommy

> On Nov 26, 2015, at 2:58 PM, Daniel Migault <daniel.miga...@ericsson.com> 
> wrote:
> 
> Hi Paul and Tommy, 
> 
> Please find the new update of the draft:
> 1) text in the introduction has been added to specify the IoT use case, and 
> the motivations for having IoT considerations in this document.
> 2) IoT has been indicated in the tables with a comment specifying that the 
> requirement is for IoT interoperability. I was not able to have two lines in 
> the postamble. It seems  is not accepted as a children for 
> 
> 3) RFCs have been added in the reference section to enable xml2rfc to run 
> properly.
> 
> The update is available here:
> https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26443652
>  
> <https://github.com/mglt/drafts/commit/8c125fa2a82af21a44c5035c3311938d26443652>
> 
> Feel free to comment update the text.
> 
> BR, 
> Daniel
> 
> 
> On Mon, Nov 23, 2015 at 11:20 AM, Paul Wouters <p...@nohats.ca 
> <mailto:p...@nohats.ca>> wrote:
> On Fri, 20 Nov 2015, Tommy Pauly wrote:
> 
> On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, 
> PRF_AES128_CBC, AUTH_AES-XCBC) are
> justified as being present for the purposes of Internet of Things devices. I 
> tend to think that it would be
> more straightforward to have a separate document that explains the preferred 
> algorithms for IoT devices (an
> IKEv2 profile for IoT, for example). However, if we do want to keep them in 
> this document, I think it would
> help to have a section in the introduction to the document explaining the use 
> case for the IoT devices and
> why they are now included in the bis document, whereas they were not relevant 
> yet in RFC 4307. It may also
> be helpful to qualify the SHOULDs as pertaining more, perhaps, to servers; 
> traditional VPN clients would
> generally not be interacting with IoT devices directly, and thus would have 
> little reason to implement
> these algorithms.
> 
> I would suggest if we want to do that, to just use a [*] notation where
> the [*] gets explained as "For interoperability with IoT clients only"
> 
> I would not want to leave it out because that will cause us to get
> servers that won't support IoT devices.
> 
> Paul
> 
> 
> ___
> IPsec mailing list
> IPsec@ietf.org <mailto:IPsec@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipsec 
> <https://www.ietf.org/mailman/listinfo/ipsec>
> 

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

Re: [IPsec] RFC 4307bis

[Tommy Pauly]

Hello Daniel,

One minor typo: "PRF_AES128_CBC has been downgraded from SHOULD in RFC4307” 
should be "PRF_AES128_CBC has been downgraded from SHOULD+ in RFC4307"

On a broader note, many of the SHOULD algorithms (ENCR_AES_CCM_8, 
PRF_AES128_CBC, AUTH_AES-XCBC) are justified as being present for the purposes 
of Internet of Things devices. I tend to think that it would be more 
straightforward to have a separate document that explains the preferred 
algorithms for IoT devices (an IKEv2 profile for IoT, for example). However, if 
we do want to keep them in this document, I think it would help to have a 
section in the introduction to the document explaining the use case for the IoT 
devices and why they are now included in the bis document, whereas they were 
not relevant yet in RFC 4307. It may also be helpful to qualify the SHOULDs as 
pertaining more, perhaps, to servers; traditional VPN clients would generally 
not be interacting with IoT devices directly, and thus would have little reason 
to implement these algorithms.

Thanks,
Tommy

> On Nov 20, 2015, at 8:28 AM, Daniel Migault  
> wrote:
> 
> Hi, 
> 
> Please find an new update: 
> https://github.com/mglt/drafts/commit/1854f98fdc1ee340565d6758e8d4642500af1c2f
>  
> 
> 
> Change 1: AUTH_AES_XCBC_96 and PRF_AES128_CBC are set to SHOULD instead of a 
> MAY. I was suprised PRF was already SHOULD. In each case, explanation text 
> has been added.
> 
> Change 2: Titles of the subsections have also been updated to better fit IANA 
> designation.
> Change 3: Sections have been re-ordered so from Typpe 1 / Type 3 / Type 2 / 
> Type 4 to Type 1/ Type 2/ Type 3 / Type 4.
> 
> Feel free to comment.
> 
> BR, 
> Daniel
> 
> 
> 
> 
> On Wed, Nov 18, 2015 at 4:04 PM, Daniel Migault  > wrote:
> Hi Yaron, 
> 
> I just committed your correction. You are right this is much better.
> 
> BR, 
> Daniel
> 
> On Mon, Nov 16, 2015 at 12:41 PM, Yaron Sheffer  > wrote:
> Looks good. One small correction:
> 
> many IKEv2 have not implemented => many IKEv2 implementations do not include
> 
> Thanks,
> Yaron
> 
> 
> On 11/16/2015 06:05 PM, Daniel Migault wrote:
> Hi,
> 
> Thank you Yaron for your comments. Please find the new update ot the draft:
> 
> https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002
>  
> 
> 
> Comment 1:
> IKEv1 is out of scope of this document. IKEv1 is deprecated and the
> recommendations of this documentmust not be considered for IKEv1.
> 
> I change MUST NOT in must not. I left the whole sentence as I beleive,
> it provides the reason why IKEv1 is not in scope and state clearly that
> applying considerations in this document to IKEv1 is a bad idea.
> 
> Comment 2:
> I added some clarifying text on why not MUST. To me the obvious reason
> is that an algorithm not mentioned in RFC4307 should not have a status
> greater than SHOULD -- unless otherwise of course ;-). I though we had
> this explanation somewhere, but maybe it is missing and should be added
> in the intro for example.
> 
> I also provided dome explanation why ESP and IKEv2 are in a different
> race which resulted in having AES-GCM not widely deployed for IKEv2
> 
> Comment 3:
> "As it is not being deployed" as been replaced by "as it is not widely
> deployed"
> 
> "and now it is known to be weak at least for a nation state" has been
> changed to "and now it is known to be weak against a nation-state attacker".
> 
> Acknowledgement section has also been updated.
> 
> BR,
> Daniel
> 
> 
> On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen  
> >> wrote:
> 
> Yaron Sheffer writes:
> > The rationale for GCM describes why it's in the table, but seems to
> > argue for a MUST (rather than the SHOULD that's in the table). I guess
> > there's a reason why we don't have MUST, let's spell it out.
> 
> The reason for that is that it is not needed as IKEv2 SA is never used
> to transmit huge amounts of data, thus the speed benefits you might
> get from there is not needed. Also support for the combined modes do
> require support for RFC5282, and there are implementations which have
> not done that (as there is no benefits or need for them to implement
> it).
> --
> kivi...@iki.fi   >
> 
> ___
> IPsec mailing list
> IPsec@ietf.org   >
> https://www.ietf.org/mailman/listinfo/ipsec 
> 
> 
> 
> 
> 

[IPsec] Discussing TCP Encapsulation of IPSec in Yokohama

[Tommy Pauly]

Hello all,

We’ll be having an informal meeting here in Yokohama to discuss TCP 
encapsulation for IPSec/IKEv2 (draft-pauly-ipsecme-tcp-encaps-00) tomorrow, 
Thursday, Nov 5, at 12pm. 

Anyone who’s interested in joining to discuss, please meet at the registration 
desk at noon!

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

Re: [IPsec] Split DNS in IKEv2 Configuration Payload

[Tommy Pauly]

Hello all,

Based on the conversation on the IPSec list previously about supporting Split 
DNS in IKEv2, Paul and I have written up a draft to add support for Split DNS 
(as well as DNSSEC) to the configuration attributes for IKEv2.

We’d like to get feedback from the working group about the level of interest in 
this topic, and if people would like to work on adopting it.

Thanks!
Tommy

===

A new version of I-D, draft-pauly-ipsecme-split-dns-00.txt
has been successfully submitted by Tommy Pauly and posted to the
IETF repository.

Name:   draft-pauly-ipsecme-split-dns
Revision:   00
Title:  Split-DNS Configuration for IKEv2 
Document date:  2015-09-24
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-00.txt 
<https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-00.txt>
Status: https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ 
<https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/>
Htmlized:   https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-00 
<https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-00>


Abstract:
  This document defines two new Configuration Payload Attribute Types
  for the IKEv2 protocol that together define a set of private DNS
  domains which should be resolved by DNS servers reachable through an
  IPsec connection, while leaving all other DNS resolution unchanged.
  This allows for split-DNS views for multiple domains and includes
  support for private DNSSEC trust anchors.  The information obtained
  via the new attribute types can be used to reconfigure a locally
  running DNS server with DNS forwarding for specific private domains.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org 
<http://tools.ietf.org/>.

The IETF Secretariat

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

Re: [IPsec] WG Interest in TCP Encapsulation

[Tommy Pauly]

Hi Valery,

As Samy mentioned, this draft does allow for the traffic to looks like HTTPS 
traffic (using TLS over port 443), but doesn’t require it. It is about defining 
a standard way to add framing to IKEv2 and ESP when put over a TCP-based 
stream; the applications of this may vary in different networks in the future.

You asked about how widespread this issue is. I cannot provide exact numbers 
here, but on a global scale, I would estimate that around 10% of networks that 
mobile customers may be using will block UDP traffic, but allow traffic 
encapsulated as we define in the draft. These are most common in hotels, 
restaurants, and other public networks.  This is certainly not the majority of 
networks, but it is still very significant to users. These failures also 
account for essentially all of the IKEv2 connection failures that we have 
measured. When IKEv2 over WiFi is used as your only way to send or receive 
phone calls, or a device is required by policy to use IKEv2 for all its 
networking connections, being on a network that blocks this traffic means 
having an unusable device. Because scenarios like this are becoming more 
common, we are seeing a push to make IKEv2 compatible with these networks. 

The primary goal of the draft is to define a standard way of framing so we 
don’t end up with a different approach from each vendor, as we saw in TLS VPNs. 
The problem is a current one that needs to be solved, since it has high user 
impact. I also believe that having a standard way to transmit IKEv2 and ESP 
over a stream-based protocol will be useful going forward, and the draft 
specifically defines exactly what is needed to be interoperable and functional, 
without creating limitations about usage scenarios (specific port numbers, TLS 
parameters, etc). 

Thanks,
Tommy

> On Sep 18, 2015, at 11:28 AM, Samy Touati  wrote:
> 
> Hi Valery,
> 
> The draft doesn't prevent http encapsulation for the purpose of traversing 
> web proxies for example, and this would be considered one "use-case" that 
> would make use of TCP encapsulation. The draft do provide such flexibility. 
> 
> The objective of this proposal is to provide a standardized method to allow 
> the use of IPSec in environments which may not allow udp encapsulated IPSec 
> traffic, and to avoid different implementations to address specific use 
> cases. 
> The client would select this method only as a last resort option, so 
> performance issues should be mitigated. 
> 
> With this capability, the mobile device can enable wifi calling in a higher 
> number of locations. It also allow the introduction of the wifi calling 
> service without too much impact in some venues types. 
> 
> 
> 
> 
> Thanks
> Samy. 
> 
> 
> 
> 
> 
> 
>> On Sep 18, 2015, at 6:54 AM, Valery Smyslov > > wrote:
>> 
>> Hi Tommy, 
>>> The real question is whether the networks that don't transport ESP or
>>> ESPinUDP block those packets on purpose or by accident. I don't think
>>> we really have any good numbers on this.
>>> If we are doing this as a "workaround" to break through the administrative
>>> boundaries, than we are going to see TCP blocked as well on those
>>> networks. And all we have gained is complexity. We'll end up playing the
>>> game of TOR.
>>> I can see some networks which legitiably block or fail to transport UDP,
>>> for instance an airplane wifi with proxy server on board for DNS and
>>> HTTP. Here, the resources are very scarce. But also, the packet loss
>>> scenario would be bad, eg when doing voice UDP over IPsec in TCP via a
>>> proxy TLS server. I did not re-read the old or read the new draft yet,
>>> but turning a UDP protocol into TCP (or even TCP in TCP) has its issues.
>>> So people want to do this anyway, and if they do, we should at least try
>>> and avoid the same scattering that has happened with TLS VPN's and do
>>> it in one interoperable way for IKE and IPsec. And I would think getting
>>> the ESPinTCP will actually be the harder part to get properly supported
>>> inside the kernels.
>>> So I would reluctantly want to move forward with the idea, although I
>>> need to do more homework about the implementation details of both drafts.
>>> Paul
>> 
>> I  to agree with Paul here. 
>> The question for me is - what do we want to achieve. If the purpose
>> is to be able to work in those environments, where UDP is blocked,
>> while TCP isn't, then we will soon end up defining IKE and ESP
>> over HTTP(S), because it is the most "penetrating" protocol right now.
>> 
>> Do you have any real numbers of how often such environments where UDP is 
>> blocked, but TCP (not only TCP:80) is not appear in real life? Could you 
>> estimate a percentage?
>> 
>> So, I'm not yet convinced that it is a solution to essentially
>> widespread problem, however if people run IKE over TCP anyway, then
>> it is better to have some standard way to do it. The question - why
>> do they do it and does 

Re: [IPsec] WG Interest in TCP Encapsulation

[Tommy Pauly]

Hi Paul,

I encourage you to read the new draft, as I believe it addresses many of your 
concerns. It covers the potential new vulnerabilities (RST), as well as how to 
frame the datagrams in a stream along with an explanation of performance 
concerns. It also makes it clear that TCP should only be used when absolutely 
necessary, not as a default.

In our own deployments around the world, there are a high number of networks 
that are blocking connections by “accident", not by policy. These include many 
hotel and restaurant networks. We are interested in allowing connections to 
work in these networks. If a network legitimately wants to block our traffic 
and is able to detect that we are using IPSec, then I am not interested in 
getting into an arms race to get around their firewalls.

Some clients may have trouble putting ESP over TCP, as you mention, but we have 
been able to implement this protocol successfully for both clients and servers. 
This may not be a protocol that all clients end up supporting, but those that 
do need TCP encapsulation should do it in a standard fashion.

As you mention, the critical point is that clients and servers will be 
implementing this functionality in the near future, and we need to avoid 
non-interoperable solutions. If we can standardize the way TCP encapsulation 
“should” work, then IKEv2 will be able to used in essentially all scenarios 
that support non-standard TLS VPN protocols. 

Thanks,
Tommy



> On Sep 17, 2015, at 10:05 AM, Paul Wouters  wrote:
> 
> On Wed, 16 Sep 2015, Yoav Nir wrote:
> 
>> This draft is proposing both IKE and ESP over the TCP connection, so the 
>> protocol will work in situations where UDP (even with fragmentation at the 
>> IKE rather than IP layer) fails.
>> 
>> We’ve had something like this working with IKEv1 for over 10 years. Many 
>> vendors have “SSL VPN” solutions that have pretty much the same performance, 
>> scalability, and connectivity characteristics. There’s ample evidence that 
>> this kind of solution works. And although the need is slowly diminishing 
>> (more and more public networks allow IKE and IPsec to work), there are still 
>> many places where we still need to tunnel everything over TCP.
> 
> The real question is whether the networks that don't transport ESP or
> ESPinUDP block those packets on purpose or by accident. I don't think
> we really have any good numbers on this.
> 
> If we are doing this as a "workaround" to break through the administrative
> boundaries, than we are going to see TCP blocked as well on those
> networks. And all we have gained is complexity. We'll end up playing the
> game of TOR.
> 
> I can see some networks which legitiably block or fail to transport UDP,
> for instance an airplane wifi with proxy server on board for DNS and
> HTTP. Here, the resources are very scarce. But also, the packet loss
> scenario would be bad, eg when doing voice UDP over IPsec in TCP via a
> proxy TLS server. I did not re-read the old or read the new draft yet,
> but turning a UDP protocol into TCP (or even TCP in TCP) has its issues.
> 
> Also TCP VPN connections can be trivially forced to close by
> sending a (spoofed) RST packet.
> 
> So, while I am sceptical, we do see a flourishing of non-interoperable
> TLS based VPN's without proper specifiations that are succesful precisely
> because it works in both bad and administratively restricted networks.
> 
> So people want to do this anyway, and if they do, we should at least try
> and avoid the same scattering that has happened with TLS VPN's and do
> it in one interoperable way for IKE and IPsec. And I would think getting
> the ESPinTCP will actually be the harder part to get properly supported
> inside the kernels.
> 
> So I would reluctantly want to move forward with the idea, although I
> need to do more homework about the implementation details of both drafts.
> 
> Paul
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec=BQIGaQ=eEvniauFctOgLOKGJOplqw=p3wIGO08_H-OJhunJTPABw=NS8d18flBXl5ifdG12-KKND7GHXI1pJTsHY3oN8YLqQ=QAyt5Max6LT-7yXfOOEqnhdsFfHCwuR1Y7YO-htB98A=
>  

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

Re: [IPsec] WG Interest in TCP Encapsulation

[Tommy Pauly]

Hello Tero,

I have read the previous draft for using TCP to avoid fragmentation problems, 
and I believe that the new TCP-encapsulation draft is aimed at solving a 
different use case with a different approach.

The current standard for IKEv2 fragmentation is definitely the right thing to 
do to avoid problems with networks that treat large UDP packets badly, causing 
IKEv2 tunnel establishment problems. The new spec is very specifically targeted 
at networks that block all UDP traffic, to be used as a fallback mechanism only.

Here’s a quick point-by-point comparison:

draft-ietf-ipsecme-ike-tcp-01 (old draft)
1. Negotiated with an IKEv2 Notify payload.
2. IKE messages can use UDP or TCP within a single SA
3. Supports IKE packets only.
4. TLS/firewall traversal/ESP-in-TCP are non-goals. This draft was meant to be 
used always, and putting all traffic over TCP or TLS had too high overhead.

draft-pauly-ipsecme-tcp-encaps-00 (new draft)
1. Non-negotiated, but pre-configured. Since the use case assumes that all UDP 
is blocked, a connection must try over TCP without prior communication if UDP 
gets no response.
2. All packets for a given IKE SA must use either UDP or TCP, with the 
exception of migration over MOBIKE.
3. Encapsulates IKE and ESP packets, since the tunnel must also go over TCP on 
a UDP-unfriendly network.
4. TLS and firewall traversal is the goal. This draft is meant to be used only 
as a last resort, and details many performance considerations to explain why 
the tunnel will work sufficiently, but is not ideal.

I agree with the decision previously to go with IKEv2 fragmentation rather than 
TCP. However, shipping clients still have serious problems on networks that do 
block UDP traffic. There may always be some middle boxes that do enough 
inspection and want to block IKE/IPSec traffic, even over TCP and TLS, but the 
majority of cases in which IKEv2 cannot be used will be, in our experience, 
solved by moving the connection to TCP/TLS when needed.

Other standards bodies, such as 3GPP, have published documents stating that 
clients should do this for IWLAN, without giving specifics on how the framing 
should be handled, or how it impacts the IKEv2 protocol. See: 
http://www.etsi.org/deliver/etsi_ts/133400_133499/133402/12.05.00_60/ts_133402v120500p.pdf

If IKEv2 servers start implementing support for TCP encapsulation based on 
these documents, we may end up with diverging implementations, or 
implementations that are not compatible with MOBIKE, etc. We believe that a 
standard is needed to define how implementations should handle this.

Thanks,
Tommy

> On Sep 15, 2015, at 7:01 PM, Tero Kivinen <kivi...@iki.fi> wrote:
> 
> Tommy Pauly writes:
>> I wanted to get a sense of WG interest in working on a standard for running
>> IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks that
>> currently block UDP traffic.
> 
> Before we made the UDP framentation document, our original plan was to
> run IKEv2 over TCP, just because that would solve this problem.
> 
> During this process we then found out that WG wanted to standardize
> UDP fragmentation instead of IKEv2 over TCP.
> 
> Is there really happend something that changes that?
> 
> The old informal poll can be found from 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__marc.info_-3Ft-3D13632609353-26r-3D1-26w-3D1=BQICAg=eEvniauFctOgLOKGJOplqw=p3wIGO08_H-OJhunJTPABw=YwqtMpmTqLSFY01PopC4Ane63G1nyZ04LeAcZPn94us=uizqLw8LM5bxVJAGGXyM2XfMCL4pT-B5pYfWxblhIEU=
>  
> 
> So how does your draft relate to the earlier ike over tcp draft? 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dipsecme-2Dike-2Dtcp_=BQICAg=eEvniauFctOgLOKGJOplqw=p3wIGO08_H-OJhunJTPABw=YwqtMpmTqLSFY01PopC4Ane63G1nyZ04LeAcZPn94us=o7KJL1YNdcjmDXh8Nc2klEkemDtBi8TQ98-hMj-1q6k=
>  
> -- 
> kivi...@iki.fi

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

[IPsec] WG Interest in TCP Encapsulation

[Tommy Pauly]

Hello,

I wanted to get a sense of WG interest in working on a standard for running 
IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks that 
currently block UDP traffic.

Here’s the link to the draft:
https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-00 
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpauly-2Dipsecme-2Dtcp-2Dencaps-2D00=BQMFaQ=eEvniauFctOgLOKGJOplqw=p3wIGO08_H-OJhunJTPABw=YU3nOZToRdXNNjQ3fAzaZFdnwRLcK4y3uWwnHWtbY-U=EfG7Pdn-bIObEeQ216ZKhaJApVAA__0qkL7NeZ-AUMY=>

Abstract:
This document describes a method to transport IKEv2 and IPSec packets
   over a TCP connection for traversing network middleboxes that may
   block IKEv2 negotiation over UDP.  This method, referred to as TCP
   encapsulation, involves sending all packets for tunnel establishment
   as well as tunneled packets over a TCP connection.

For clients that rely heavily on IKEv2, such as phones that use IKEv2 to to 
route VoIP calls over Wi-Fi back to carrier networks, working in such networks 
in critical.

Please respond with your comments!

Thanks,
Tommy Pauly
Apple___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec