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

[Michael Richardson]

Paul Wouters  wrote:
>> It seems that a reasonable implementation might spawn off many
>> TCP-IKE-ESP daemons (perhaps even via TCP-load balancer proxy) to demux
>> and decapsulate the traffic, turning it into real ESP and real IKE
>> packets,
>> and send it to an existing daemon.

> If it is just TCP without any TLS wrapper, a "reasonable" host would
> really do this inside the kernel without copying back and forth between
> userland.

Linux XDP can probably do it in a way that can be offloaded.

> Once TLS is involved, things become different, unless you want to build
> a TLS stack into the kernel :P

There are a multitude of TLS accelerators that live "below" the kernel.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Michael Richardson]

Tero Kivinen  wrote:
> Actually no. Unknown SPI is something that can happen in normal case
> too, as there are some race conditions which might cause the one end
> to install the Child SA before the other end has installed it, thus
> this might cause message with unknown SPI to come in. On the other
> hand as TCP is reliable transport, there are less changes of this to
> happen, but I think it can still happen, as the IKE packets and ESP
> packets can be reordered inside the processing host, i.e., even if
> host A sends IKE packet creating the Child SA first, and then

I agree that reording could happen inside the "host"

It seems that a reasonable implementation might spawn off many
TCP-IKE-ESP daemons (perhaps even via TCP-load balancer proxy) to demux
and decapsulate the traffic, turning it into real ESP and real IKE packets,
and send it to an existing daemon.



--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

Yoav Nir writes:
> But since Tommy’s happy with tearing down the connection after one invalid
> SPI, that solves the problem nicely.

I do not think we want to do that. There are valid cases where we
might get unknown SPIs, so tearing connection down after one of those
is not good solution. 

> By the way: do we tear it down after one bad MAC as well?

We should never get bad MACs for known SPIs unless there is corruption
in the packet, thus that always indicates that there is either
attacker modifying the packets, or uncorrectable bit errors in
transit, or buggy implementation.

So tearing it down after one bad MAC would be acceptable, as those
should not happen in normal situations. If we get lots of packets with
unknown SPIs then we should also tear it down, but not for the first
such event, especially if the SPIs are same. So perhaps tear it down
when we receive more than n frames with unknown SPIs, or when we
receive one frame which fails ESP or IKE authentication MAC checks.
-- 
kivi...@iki.fi

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

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

[Tero Kivinen]

Tommy Pauly writes:
> 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.

Yes, adding paragraph break will make it more explicit, so please, do so.

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

Actually no. Unknown SPI is something that can happen in normal case
too, as there are some race conditions which might cause the one end
to install the Child SA before the other end has installed it, thus
this might cause message with unknown SPI to come in. On the other
hand as TCP is reliable transport, there are less changes of this to
happen, but I think it can still happen, as the IKE packets and ESP
packets can be reordered inside the processing host, i.e., even if
host A sends IKE packet creating the Child SA first, and then
immediately followed by the ESP packet using that Child SA, it might
be possible that IKE packet is still being processed when the ESP
packet arrives, and ESP packet might hit unknown SPI error because of
that. 

On the other hand if you receive several messages where the
message authentication failes (i.e., ICV check fails), then that is
good indication that something is wrong. 

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

I think it would be good idea to say that if the TCP stream looks like
being corrupted, then close the TCP stream and try with new TCP
stream.

Note, that this is DoS attack we cannot defend against when using
IPsec encapsulated in the TCP. Attackers can always do DoS by either
deleting packets, or sending RST frames or modifying frames in
transit.

We should try to recover from easy attacks, like sending one RST frame
(we just recreate TCP session), or modifying single byte in transit
(skip it, but if too many errors come in, restart TCP).

> So the attacker can cause one large frame to be read, but after that the
> connection will be torn down.

Also as the frame inside the TCP stream has 16-bit length field, it
cannot even cause the other end to read big packet, just less than 64k
packet. If we would have 32-bit lenght field this issue would be much
bigger, as then we would need to add timer while reading the frame, or
add max length checks for the packet.

Now, we can safely assume that other end will send enough data that we
have the packet specified by the length. If there are enough parsing
errors while reading packets, we drop the TCP session. 
-- 
kivi...@iki.fi

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

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

[Yoav Nir]

> On 17 May 2017, at 22:12, Scott Fluhrer (sfluhrer)  wrote:
> 
> 
> 
> 
> 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.

Oh, right.

> That said, most of us feed the IPsec stack with packets generated on networks 
> with an MTU of 1500. Even if we add the IPsec over head on top of that, it’s 
> still less than 2.5% of the space afforded by a 16-bit length field. At least 
> for ESP packets.
> 
> If the receiver were to break the connection whenever it received some number 
> (2?  3?) of packets that had a length field that exceeded 1544 (or whatever 
> the maximum packet is for the particular algorithm) followed by an ESP field 
> that was not zero,
> 
> “ESP field”; do you mean SPI?

Yes, sorry.

> 
> this would fix the problem without letting Eve break the connection with just 
> one injected byte.
> 
> I f you don’t’ use IKE fragmentation, then I believe IKE packets could be 
> over the limit we picked (unless we picked a rather conservative one); would 
> that be an issue?  So, was that something you were trying to address with the 
> ESP field above?

Yes. A non-zero SPI field means ESP rather than IKE.

It’s not always true that IKE can be large but ESP is at most MTU + header. We 
used to collect fragments into a large packet and then encrypt that packet. 
With regular ESP that created a fragmented ESP (which caused endless interop 
problems with Cisco implementations), but with IKE over TCP the large ESP 
packet could be sent on the stream.  But in general, most packets are TCP or 
VoIP so most packets fit within MTU.

But since Tommy’s happy with tearing down the connection after one invalid SPI, 
that solves the problem nicely.

By the way: do we tear it down after one bad MAC as well?

Yoav



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Scott Fluhrer (sfluhrer)]

From: tpa...@apple.com [mailto:tpa...@apple.com]
Sent: Wednesday, May 17, 2017 3:44 PM
To: Scott Fluhrer (sfluhrer)
Cc: Yoav Nir; IPsecme WG (ipsec@ietf.org)
Subject: Re: [IPsec] Question about ipsecme-tcp-encaps


On May 17, 2017, at 12:12 PM, Scott Fluhrer (sfluhrer) 
<sfluh...@cisco.com<mailto:sfluh...@cisco.com>> 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<mailto:ipsec@ietf.org>)
Subject: Re: [IPsec] Question about ipsecme-tcp-encaps


On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) 
<sfluh...@cisco.com<mailto:sfluh...@cisco.com>> 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 ca

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

[Tommy Pauly]

> On May 17, 2017, at 12:12 PM, Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> 
> wrote:
> 
>  
> From: Yoav Nir [mailto:ynir.i...@gmail.com <mailto:ynir.i...@gmail.com>] 
> Sent: Wednesday, May 17, 2017 2:54 PM
> To: Scott Fluhrer (sfluhrer)
> Cc: IPsecme WG (ipsec@ietf.org <mailto:ipsec@ietf.org>)
> Subject: Re: [IPsec] Question about ipsecme-tcp-encaps
>  
>  
> On 17 May 2017, at 20:39, Scott Fluhrer (sfluhrer) <sfluh...@cisco.com 
> <mailto:sfluh...@cisco.com>> 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 
byte

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

[Scott Fluhrer (sfluhrer)]

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) 
<sfluh...@cisco.com<mailto:sfluh...@cisco.com>> 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?
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)


Thoughts?

I’d like to hear how TCP stacks really behave.

That said, most of us feed the IPsec stack with packets generated on networks 
with an MTU of 1500. Even if we add the IPsec over head on top of that, it’s 
still less than 2.5% of the space afforded by a 16-bit length field. At least 
for ESP packets.

If the receiver were to break the connection whenever it received some number 
(2?  3?) of packets that had a length field that exceeded 1544 (or whatever the 
maximum packet is for the particular algorithm) followed by an ESP field that 
was not zero,

“ESP field”; do you mean SPI?

this would fix the problem without letting Eve break the connection with just 
one injected byte.

I f you don’t’ use IKE fragmentation, then I believe IKE packets could be over 
the limit we picked (unless we picked a rather conservative one); would that be 
an issue?  So, was that something you were trying to

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

[Yoav Nir]

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

> 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?
> 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)
> 
> 
> Thoughts?

I’d like to hear how TCP stacks really behave.

That said, most of us feed the IPsec stack with packets generated on networks 
with an MTU of 1500. Even if we add the IPsec over head on top of that, it’s 
still less than 2.5% of the space afforded by a 16-bit length field. At least 
for ESP packets.

If the receiver were to break the connection whenever it received some number 
(2?  3?) of packets that had a length field that exceeded 1544 (or whatever the 
maximum packet is for the particular algorithm) followed by an ESP field that 
was not zero, this would fix the problem without letting Eve break the 
connection with just one injected byte.

But there does seem to be something missing.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec