[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)
From: Tommy Pauly <tpauly () apple ! com>
Date: 2017-05-31 18:37:27
Message-ID: 34C32236-D200-421F-AF6E-F953DA79A869 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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 <tpauly@apple.com> wrote:
>
>
>
> > On May 8, 2017, at 5:49 AM, Mirja Kuehlewind (IETF) <ietf@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 <ekr@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<whatever>, 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.ietf@gmail.com> wrote:
> > >
> > > On May 3, 2017 05:54, "Mirja Kühlewind" <ietf@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.
> > >
> > >
> > >
> >
>
[Attachment #5 (text/html)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><div class="">Hello,</div><div class=""><br \
class=""></div><div class="">I've posted a new version of the draft that incorporates \
the changes discussed in this thread. Please review!</div><div class=""><br \
class=""></div><div class=""><a \
href="https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10" \
class="">https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10</a></div><div \
class=""><br class=""></div><div class="">Thanks,</div><div class="">Tommy</div><br \
class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 12, \
2017, at 3:25 PM, Tommy Pauly <<a href="mailto:tpauly@apple.com" \
class="">tpauly@apple.com</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br \
class=""><blockquote type="cite" class="">On May 8, 2017, at 5:49 AM, Mirja \
Kuehlewind (IETF) <<a href="mailto:ietf@kuehlewind.net" \
class="">ietf@kuehlewind.net</a>> wrote:<br class=""><br class="">Does the \
proposed text changes from Tommy still refer to 443 anywhere (lost track a bit but I \
guess the appendix still does right)?<br class=""><br class="">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.<br class=""></blockquote><br \
class="">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.<br class=""><br class=""><blockquote type="cite" class=""><br \
class="">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.<br \
class=""></blockquote><br class="">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.<br class=""><br class="">Thanks,<br \
class="">Tommy<br class=""><br class=""><blockquote type="cite" class=""><br \
class="">Mirja<br class=""><br class=""><br class=""><blockquote type="cite" \
class="">Am 05.05.2017 um 23:13 schrieb Eric Rescorla <<a \
href="mailto:ekr@rtfm.com" class="">ekr@rtfm.com</a>>:<br class=""><br class="">It \
seems like most of the issues are resolved here, except for that of muxing<br \
class="">IKE and non-IKE protocols on the same port (especially 443). My \
understanding<br class="">is that (although we may not like it) it's nevertheless a \
common practice, and<br class="">yet we can't levy the requirement that no other \
protocol start with IKETCP<whatever>,<br class="">so it seems like what we need \
is a warning note and potentially a request to reserve<br class="">this string for \
some set of common protocols (HTTP,...?).<br class=""><br class="">Mirja, would that \
work for you?<br class=""><br class="">-Ekr<br class=""><br class=""><br class="">On \
Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF <<a \
href="mailto:spencerdawkins.ietf@gmail.com" \
class="">spencerdawkins.ietf@gmail.com</a>> wrote:<br class=""><br class=""><br \
class="">On May 3, 2017 05:54, "Mirja Kühlewind" <<a \
href="mailto:ietf@kuehlewind.net" class="">ietf@kuehlewind.net</a>> wrote:<br \
class="">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.<br class=""><br class="">Fwiw, that would work for me.<br \
class=""><br class="">Spencer<br class=""><br class=""><br class=""><br \
class="">Mirja<br class=""><br class=""><br class=""><br class="">On 03.05.2017 \
11:12, Tero Kivinen wrote:<br class="">Mirja Kuehlewind (IETF) writes:<br class="">my \
thinking was that the main problem is that 3947 was not obsoleted<br class="">and I'm \
assuming we need a document to fix that.<br class=""><br class="">This is partly \
issue, but it is not issue we need to solve here, as<br class="">this document is not \
something that should obsolete 3947.<br class=""><br class="">Also 3947 only defines \
extension for the IKEv1 (RFC2409) and that is<br class="">already obsoleted, so \
effectively RFC3947 is already obsoleted, as<br class="">there is no way to implement \
3947 without implementing obsoleted<br class="">protocol...<br class=""><br \
class="">This issue is not not important enough to require RFC now.<br class=""><br \
class="">In this case that document could/should also fix the IANA entry for<br \
class="">the UDP port. However, I'm actually not sure what the right<br \
class="">processing would be to fix this forgotten obsolete… maybe other ADs<br \
class="">know better…?<br class=""><br class="">For now I would just leave it as it \
is, but fix the references in the<br class="">IANA registry so that document will not \
be referenced, especially as<br class="">the original IANA reference was not to the \
correct RFC in the first<br class="">place.<br class=""><br class="">Otherwise if you \
don't want to do this, I don't think it's a good<br class="">idea to merge kind of \
unrelated fixes into this spec. We can also<br class="">fix that by using the IESG \
approval process (see RFC5226). I think<br class="">that's the better option!<br \
class=""><br class="">That is true, but as this document already modifies the \
TCP/4500<br class="">reference, fixing the UDP/4500 reference at the same time is \
not<br class="">completely unrelated fix.<br class=""><br class="">Obsoleting RFC3947 \
would be unrelated fix.<br class=""><br class=""><br class=""><br \
class=""></blockquote><br class=""></blockquote><br \
class=""></div></div></blockquote></div><br class=""></body></html>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic