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

[Hu, Jun (Nokia - US)]

I think this is similar case as NAT-T , where system need to update 
address:port if NAT mapping is changed ( described in last point of 2.23 of 
RFC7296 ); 
RFC 7296 says: "dynamic address update should only
  be done in response to a new packet; otherwise, an attacker can
  revert the addresses with old replayed packets.  Because of this,
  dynamic updates can only be done safely if replay protection is
  enabled."

I think we could use same requirement (pass anti-replay) here since this is 
same issue and tcp encap is not make thing worse; 

> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Valery Smyslov
> Sent: Thursday, January 12, 2017 7:26 AM
> To: 'Tero Kivinen' 
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] Review of the draft-ietf-ipsecme-tcp-encaps-04
> 
> > > > Initiator then recreates tcp session with responder and sends some
> > > > ESP traffic with sequence numbers of 0x1001-0x1005. Attacker kills
> > > > that TCP connection, creates completely new TCP session and
> > > > replays the old ESP message with sequence number of 0x1000 (which
> > > > was not seen by the server before). Responder will accept this as
> > > > valid non replayed ESP packet, and will move all traffic to this new TCP
> connection.
> > >
> > > What then? What benefits attacker gains and how it will exploit the
> > > fact it hijacks TCP connection? The responder will eventually
> > > recreate new TCP connection and everything will continue to work.
> >
> > As I said this is not serious, but it is vulnerability, which is easy
> > to fix.
> 
> I don't think your fix really helps in this scenario.
> 
> If attacker intercepts TCP session carrying ESP packet with sequence
> 0x1000 and manages to get the packet and drop the TCP session before
> responder gets it, then it can create a new TCP session sending this packet.
> The responder will switch to the attacker's TCP session even with your
> proposal (until the initiator creates new TCP session and sends some ESP
> packets with higher SN).
> 
> 
> ___
> 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]

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] Review of draft-pauly-ipsecme-split-dns-02

[Paul Wouters]

On Thu, 12 Jan 2017, Tero Kivinen wrote:


I might not want to trust the VPN gateway of our partner claiming to
be authorative for mycompany.com, i.e., I will have policy limiting
what is accepted from the gateway.

Also when using opportunistic authentication we might want to have
even strictier policies.


OK, then it contradicts with your own comment that all requests to
INTERNAL_DNS_DOMAIN MUST be done using internal DNS server.
Quoting your message:

I think the 1st point (I.e. all requests about internal names go to
the internal servers) is something that is important for security, so
it should perhaps be MUST.

At least it must be clarified.


Yes, and No. If the client rejects the INTERNAL_DNS_DOMAIN because of
policy reasons, then it is not internal name anymore, thus it can use
DNS server configured elsewhere. But yes, I agree there should be
clarification explaining that only those internal names client
accepted must use internal servers...


Remember ipsec is peer to peer, not client to server :)

The idea is that the client can convey information of which DNS it will
allow to be stolen and the server can convey which DNS it is serving
that is expected to be an internal dns domain (eg different from outside
worldview).

This is not about the server offering a DNS server to take all your
queries. For that, I believe you can use the existing options, and
those are outside the scope of this document.

Paul

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

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

[Valery Smyslov]

> > > Initiator then recreates tcp session with responder and sends some ESP
> > > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that
> > > TCP connection, creates completely new TCP session and replays the old
> > > ESP message with sequence number of 0x1000 (which was not seen by the
> > > server before). Responder will accept this as valid non replayed ESP
> > > packet, and will move all traffic to this new TCP connection.
> >
> > What then? What benefits attacker gains and how it will exploit
> > the fact it hijacks TCP connection? The responder will eventually
> > recreate new TCP connection and everything will continue to work.
> 
> As I said this is not serious, but it is vulnerability, which is easy
> to fix. 

I don't think your fix really helps in this scenario.

If attacker intercepts TCP session carrying ESP packet with sequence 
0x1000 and manages to get the packet and drop the TCP session before 
responder gets it, then it can create a new TCP session
sending this packet. The responder will switch to the attacker's
TCP session even with your proposal (until the initiator
creates new TCP session and sends some ESP packets with higher SN).


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

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

[Tero Kivinen]

Valery Smyslov writes:
> > Initiator then recreates tcp session with responder and sends some ESP
> > traffic with sequence numbers of 0x1001-0x1005. Attacker kills that
> > TCP connection, creates completely new TCP session and replays the old
> > ESP message with sequence number of 0x1000 (which was not seen by the
> > server before). Responder will accept this as valid non replayed ESP
> > packet, and will move all traffic to this new TCP connection.
> 
> What then? What benefits attacker gains and how it will exploit
> the fact it hijacks TCP connection? The responder will eventually
> recreate new TCP connection and everything will continue to work.

As I said this is not serious, but it is vulnerability, which is easy
to fix. There might be tricks you can do (for example forward
multigigabyte video stream from server to some unsuspecting client,
while the original recipient is just wondering where is my video,
until after few minutes it times out and tries to recreate the TCP
session, or sends new packet through the TCP session.

> The reason I opposed your interpretation of "fresh" is that
> if you replace ESP with IKE in the example above and if you
> require the responder to ignore smaller MESSAGE_IDs if 
> the higher are received, then the responder will ignore
> IKE message with ID=0x1000 in your example, because
> this message will be received after the responder receives 0x1001-0x1005.
> Since the initiator will never receive reply for ID=0x1000 
> it will eventually kill IKE SA. This is much more dangerous
> attack than the attack you described above.

IKE will not have this issue, as every single IKE frame will require
response, thus if the original initiator did not get IKE response to
his request when the attacker killed the connection, then it will
retransmit when it recreates the TCP session. This only really affects
ESP, not IKE.

Also in IKE the window size is quite often also 1.

And, I am not saying they should ignore the messages, I say they
should not consider the messages as fresh, meaning they should not
turn old traffic to that new TCP session until they see fresh message.

> > The attack is not very efficient, and there are most likely easier
> > ways to do similar attacks, but there might be some other tricks
> > people might invent if we leave this thing open. Thats why I think it
> > is better to close it by saying that it is not enough to have valid
> > ESP packet which is not replay, but it must be valid ESP packet which
> > have sequence number that is higher than anything seen before.
> 
> For IKE it'll make things worse.

And I was talking about ESP. Not IKE. For IKE there is no problem
there as there is always response, thus blackholes are detected. For
ESP there can be problems. 

> > One way of implementing that is to configure ESP replay window size to
> > be 1...
> 
> That's probably OK, since TCP will provide in-order delivery.
> However, that will further complicate implementations, because
> you'll need to be able to dynamically manipulate ESP window
> size in case the transport changes.
> 
> And IKE doesn't allow window to shrink, so we'll stick to 
> size = 1. Not a good idea.

Again, I do not think this is needed for IKE, I think it is needed for
ESP. With ESP it is possible for the attacker to redirect the packets
from the server to wrong address for long time, by just sending few
packets, and the situation might be fixed only after the original
initiator wonders where his packets are and starts to do corrective
actions. 

(and IKE window can shrink, as rekey resets the window size to 1).
-- 
kivi...@iki.fi

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

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

[Valery Smyslov]

> > Isn't it easier to add a requirement that the received message must
> > not be a replay? For example:
> >
> > It should choose the TCP
> > connection on which it last received a valid and decryptable IKE or
> > ESP message that is not recognized as a replay of some early message.
> 
> No.
> 
> Not replay == ESP packet we have not seen before that is still in
> window != ESP packet which has largest sequence number.
> 
> I.e., attacker sends RST to the tcp connection, initiator recreates
> TCP session, and initiator sends one ESP packet to the TCP connection
> having sequence number of 0x1000. Attacker messes up with the TCP
> connection so that responder never sees the ESP 0x1000 packet, and TCP
> connection is reset. For example sends RST before the actual packet
> reaches the responder, but after the attacker has seen the contents of
> the packet in TCP stream.
> 
> Initiator then recreates tcp session with responder and sends some ESP
> traffic with sequence numbers of 0x1001-0x1005. Attacker kills that
> TCP connection, creates completely new TCP session and replays the old
> ESP message with sequence number of 0x1000 (which was not seen by the
> server before). Responder will accept this as valid non replayed ESP
> packet, and will move all traffic to this new TCP connection.

What then? What benefits attacker gains and how it will exploit
the fact it hijacks TCP connection? The responder will eventually
recreate new TCP connection and everything will continue to work.

The reason I opposed your interpretation of "fresh" is that
if you replace ESP with IKE in the example above and if you
require the responder to ignore smaller MESSAGE_IDs if 
the higher are received, then the responder will ignore
IKE message with ID=0x1000 in your example, because
this message will be received after the responder receives 0x1001-0x1005.
Since the initiator will never receive reply for ID=0x1000 
it will eventually kill IKE SA. This is much more dangerous
attack than the attack you described above.

> The attack is not very efficient, and there are most likely easier
> ways to do similar attacks, but there might be some other tricks
> people might invent if we leave this thing open. Thats why I think it
> is better to close it by saying that it is not enough to have valid
> ESP packet which is not replay, but it must be valid ESP packet which
> have sequence number that is higher than anything seen before.

For IKE it'll make things worse.

> One way of implementing that is to configure ESP replay window size to
> be 1...

That's probably OK, since TCP will provide in-order delivery.
However, that will further complicate implementations, because
you'll need to be able to dynamically manipulate ESP window
size in case the transport changes.

And IKE doesn't allow window to shrink, so we'll stick to 
size = 1. Not a good idea.


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

Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02

[Tero Kivinen]

Valery Smyslov writes:
> > > > This way if you have originally configured company1.com to the
> > > > internal dns names, and then company decides to buy another company
> > > > called company2.com, teh client can still request company1.com and
> > > > server can return both company1.com and company2.com in its reply.
> > > > Then it is up to the client whether it will belive the list or not.
> > >
> > > Why the client would ever not believe to the information from the
> > > authenticated server? I'd go further and say that the initiator MUST
> > > use the received internal DNS servers for all the requests within
> > > the received INTERNAL_DNS_DOMAIN (as you proposed before).
> > 
> > The level of trust might not be complete. I.e., if my laptop is
> > connecting to both my own VPN gateway, and also one of our partners
> > VPN gateway, I might trust the VPN gateway of our my company even if
> > it claims to provide trusted DNS delegation for .com...
> > 
> > I might not want to trust the VPN gateway of our partner claiming to
> > be authorative for mycompany.com, i.e., I will have policy limiting
> > what is accepted from the gateway.
> > 
> > Also when using opportunistic authentication we might want to have
> > even strictier policies.
> 
> OK, then it contradicts with your own comment that all requests to 
> INTERNAL_DNS_DOMAIN MUST be done using internal DNS server.
> Quoting your message:
> 
>   I think the 1st point (I.e. all requests about internal names go to
>   the internal servers) is something that is important for security, so
>   it should perhaps be MUST.
> 
> At least it must be clarified.

Yes, and No. If the client rejects the INTERNAL_DNS_DOMAIN because of
policy reasons, then it is not internal name anymore, thus it can use
DNS server configured elsewhere. But yes, I agree there should be
clarification explaining that only those internal names client
accepted must use internal servers...
-- 
kivi...@iki.fi

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

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

[Tero Kivinen]

Valery Smyslov writes:
> > 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.
> 
> Isn't it easier to add a requirement that the received message must
> not be a replay? For example:
> 
>   It should choose the TCP
>   connection on which it last received a valid and decryptable IKE or
>   ESP message that is not recognized as a replay of some early message.

No.

Not replay == ESP packet we have not seen before that is still in
window != ESP packet which has largest sequence number.

I.e., attacker sends RST to the tcp connection, initiator recreates
TCP session, and initiator sends one ESP packet to the TCP connection
having sequence number of 0x1000. Attacker messes up with the TCP
connection so that responder never sees the ESP 0x1000 packet, and TCP
connection is reset. For example sends RST before the actual packet
reaches the responder, but after the attacker has seen the contents of
the packet in TCP stream.

Initiator then recreates tcp session with responder and sends some ESP
traffic with sequence numbers of 0x1001-0x1005. Attacker kills that
TCP connection, creates completely new TCP session and replays the old
ESP message with sequence number of 0x1000 (which was not seen by the
server before). Responder will accept this as valid non replayed ESP
packet, and will move all traffic to this new TCP connection.

The attack is not very efficient, and there are most likely easier
ways to do similar attacks, but there might be some other tricks
people might invent if we leave this thing open. Thats why I think it
is better to close it by saying that it is not enough to have valid
ESP packet which is not replay, but it must be valid ESP packet which
have sequence number that is higher than anything seen before.

One way of implementing that is to configure ESP replay window size to
be 1... 

> > So I would say MUST accept packets with fragmentation from TCP if
> > fragmentation is supported and enabled. SHOULD NOT fragment packets if
> > sending them to the TCP connection.
> 
> I agree with your comment here, however I can see a reason for MAY - 
> some implementations may have a single configuration knob, that
> triggers between "always fragment" and "never fragment".
> These implementations may choose to always fragment
> (if the knob is on) regardless of the used transport just for simplicity.

So we are allowing this kind of stupid things because there might be
some implementation that will implement this new protocol and which
does not want to fix their own broken implementation about
fragmentation?

I assume they do not really care about the fragment sizes, and will
fragment everything to 100 byte fragments, just because of simplicity?

Again SHOULD will not prevent that, and MUST accept will allow them
to work... Hmm.. and the responder SHOULD respond with fragments too
if I read RFC7383 right...

On the other hand sending fragments to the TCP connection is already
against SHOULD NOT in the RFC7383 which says that "IKE fragmentation
SHOULD NOT be used in cases where IP-layer fragmentation of both the
request and response messages is unlikely."...

So I think SHOULD NOT fragment is correct here, as it is directly
derived from the RFC7383...
-- 
kivi...@iki.fi

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

Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02

[Valery Smyslov]

> > > This way if you have originally configured company1.com to the
> > > internal dns names, and then company decides to buy another company
> > > called company2.com, teh client can still request company1.com and
> > > server can return both company1.com and company2.com in its reply.
> > > Then it is up to the client whether it will belive the list or not.
> >
> > Why the client would ever not believe to the information from the
> > authenticated server? I'd go further and say that the initiator MUST
> > use the received internal DNS servers for all the requests within
> > the received INTERNAL_DNS_DOMAIN (as you proposed before).
> 
> The level of trust might not be complete. I.e., if my laptop is
> connecting to both my own VPN gateway, and also one of our partners
> VPN gateway, I might trust the VPN gateway of our my company even if
> it claims to provide trusted DNS delegation for .com...
> 
> I might not want to trust the VPN gateway of our partner claiming to
> be authorative for mycompany.com, i.e., I will have policy limiting
> what is accepted from the gateway.
> 
> Also when using opportunistic authentication we might want to have
> even strictier policies.

OK, then it contradicts with your own comment that all requests to 
INTERNAL_DNS_DOMAIN MUST be done using internal DNS server.
Quoting your message:

I think the 1st point (I.e. all requests about internal names go to
the internal servers) is something that is important for security, so
it should perhaps be MUST.

At least it must be clarified.


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

Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02

[Tero Kivinen]

Valery Smyslov writes:
> > This way if you have originally configured company1.com to the
> > internal dns names, and then company decides to buy another company
> > called company2.com, teh client can still request company1.com and
> > server can return both company1.com and company2.com in its reply.
> > Then it is up to the client whether it will belive the list or not.
> 
> Why the client would ever not believe to the information from the
> authenticated server? I'd go further and say that the initiator MUST
> use the received internal DNS servers for all the requests within
> the received INTERNAL_DNS_DOMAIN (as you proposed before).

The level of trust might not be complete. I.e., if my laptop is
connecting to both my own VPN gateway, and also one of our partners
VPN gateway, I might trust the VPN gateway of our my company even if
it claims to provide trusted DNS delegation for .com...

I might not want to trust the VPN gateway of our partner claiming to
be authorative for mycompany.com, i.e., I will have policy limiting
what is accepted from the gateway.

Also when using opportunistic authentication we might want to have
even strictier policies.
-- 
kivi...@iki.fi

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

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

[Valery Smyslov]

Hi once more,

>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.

And it should be specified that if responder times out waiting
for complete IKE message, it must not only delete IKE SA state,
but also it must close TCP connection, so that initiator get informed
that it must start over from creating new TCP connection
and resending the whole message. Otherwise if the TCP eventually
resumes, the responder will receive partial message which it'll
treat as invalid (I assume that the responder has already read from the socket 
some part of the message, like length prefix) and the TCP connection
will be closed anyway.

> --
> 
>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 will be always true with TCP.

> 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.

Isn't it easier to add a requirement that the received message must not be a 
replay?
For example:

It should choose the TCP
connection on which it last received a valid and decryptable IKE or
ESP message that is not recognized as a replay of some early message.

> --
> 
> In section 9:
> 
>fragmentation.  Even if fragmentation is negotiated, an
>implementation MAY choose to not fragment when going over a TCP
>connection.
> 
> why allow fragmentation over TCP connection? I think we could say that
> fragmentation SHOULD NOT be used when sending messages over TCP
> connection? The only reason I can think why someone would use
> fragmentation is that they are using mobike and the initiator is using
> UDP and tries to send some large message which requires fragmentation
> on UDP first, and then when the packets do not get through it tries to
> move to use TCP, and in that case it MUST forward the IKE packet just
> as it was sent over the UDP to the TCP, so the packet will have
> fragmentation headers in it.
> 
> So I would say MUST accept packets with fragmentation from TCP if
> fragmentation is supported and enabled. SHOULD NOT fragment packets if
> sending them to the TCP connection.

I agree with your comment here, however I can see a reason for MAY - 
some implementations may have a single configuration knob, that
triggers between "always fragment" and "never fragment".
These implementations may choose to always fragment
(if the knob is on) regardless of the used transport just for simplicity.

Regards,
Valery.

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

[IPsec] Review of draft-ietf-ipsecme-rfc7321bis-01

[Tero Kivinen]

Timothy Carlin writes:
> My comments:
> 
> * Section 4 mentions that that 256-bit keys are raised to the SHOULD level. 
> Should this read as these are now the MUST level as ENCR_AES_CBC and
> ENCR_AES_GCM_16 are at the MUST level according to Table 1 (with the [1]
> endnote)?

Yes, I think this is inconsistancy caused by last edits, i.e., when we
changed the 256-bit keys to MUST, we only edited the footnote, and
missed the text in section 4.

So correct change is:

OLD:

In that sense 256 bit keys
   status has been raised from MAY in RFC7321 to SHOULD.

NEW:

In that sense 256 bit keys
   status has been raised from MAY in RFC7321 to MUST.

> * Section 5 mentions ENCR_NULL_AUTH_AES_GMAC, which is not
> referenced anywhere in the document.  Should it be added to Table 1
> at the MUST level?

No. It is MAY level algorithm, just like the AUTH_AES_128_GMAC and
AUTH_AES_256_GMAC algorithms. The reason those AUTH_AES_{128,256}_GMAC
algorithms are listed here is, that they used to be SHOULD+, and are
now downgraded to MAY.

The ENCR_NULL_AUTH_AES_GMAC has been MAY, and will be MAY, so it is
not mentioned in the section 4.

Your text edits seemed to be fine.
-- 
kivi...@iki.fi

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

Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02

[Valery Smyslov]

Hi Tero,

> --
> >From section 3.2
> 
>If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non-
>zero lengths, the CFG_REPLY MUST NOT assign any domains in its
>INTERNAL_DNS_DOMAIN attributes that are not contained within the
>requested domains.  The initiator SHOULD ignore any domains beyond
>its requested list.
> 
> This whole thing about restricting the subdomains server can send by
> sending the list from client is different than what we normally do. In
> normal case the client sends list of suggestions for the configuration
> values to the server. Here the client forces server to do something.
> 
> I think it would be better to say that client can send list of dns
> names it would like to be included, and server can then reply whatever
> list it has in its configuration, and client is free to ignore as many
> of the items from the list it likes.
> 
> This way if you have originally configured company1.com to the
> internal dns names, and then company decides to buy another company
> called company2.com, teh client can still request company1.com and
> server can return both company1.com and company2.com in its reply.
> Then it is up to the client whether it will belive the list or not.

Why the client would ever not believe to the information from the authenticated 
server?
I'd go further and say that the initiator MUST use the received internal DNS 
servers 
for all the requests within the received INTERNAL_DNS_DOMAIN (as you proposed 
before).

> In section 6:
> 
>If a host connected to an authenticated IKE peer is connecting to
>another IKE peer that attempts to claim the same domain via the
>INTERNAL_DNS_DOMAIN attribute, the IKE connection should be
>terminated.
> 
> Which of the IKE connection should be terminated? Perhaps the first
> connection has died and user tried to reconnect to the same server,
> which will of course give the same INTERNAL_DNS_DOMAIN. Tearing down
> that new connection and not allowing it to be formed until the first
> one is timed out is bit annoying.

I think that tearing down a connection in this case is wrong and inconsistent 
with
Redirect Mechanism for IKEv2 (RFC5685). There could be several
VPN gateways protecting the internal network and the client
can be redirected from one to another (or even have a concurrent
IKE SAs in case of load sharing scenario).

>If the IP address value of the received INTERNAL_IP4_DNS or
>INTERNAL_IP6_DNS attribute is not covered by the proposed IPsec
>connection, then the local DNS should not be reconfigured until a
>CREATE_CHILD Exchange is received that covers these IP addresses.
> 
> I think this is dangerous. I.e. if the server returns INTERNAL_IP4_DNS
> of 10.0.0.1 and INTERNAL_DNS_DOMAIN of example.com, but initial Child
> sa connection fails for some reason (out of resources). Next the email
> client trying to resolve the mail.example.com goes out to the external
> dns servers to find the name, instead of trying to use 10.0.0.1 dns
> server. Note, that when it tries to send packet to 10.0.0.1, then the
> IPsec will simply trigger for that packet, and will create the Child
> SA needed...
> 
> So I think the DNS configuration should be done immediately,
> regardless whether the Child SA to cover those IP address is there.
> In properly configured system the IP-address will then trigger the SA
> to be created when they are first time used.

I completely agree here. As with internal IP address assignment
the failure to create IPsec SA is not a reason not to configure
internal DNS servers. 

Regards,
Valery.

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