Subject: [saag] A tale of (flawed) transient numeric identifiers (Fwd: New Version Notification for draft-gont-numeric-ids-history-00.txt)

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Jul 2016 18:23:05 +0200

Folks,

As suggested by a number of folks during the SAAG meeing in Buenos
Aires, we have submitted the history of flawed numeric IDs as a
stand-alone I-D. It is available at:
<https://www.ietf.org/internet-drafts/draft-gont-numeric-ids-history-00.txt>

We believe this information provides good background and motivation for
pursuing further work in this area, and learning about errors from the past.

Your input will be very appreciated.

Thanks!
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-numeric-ids-history-00.txt
Date: Fri, 08 Jul 2016 09:17:38 -0700
From: [email-masked]
To: Ivan Arce <[email-masked]>, Fernando Gont
<[email-masked]>

A new version of I-D, draft-gont-numeric-ids-history-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-numeric-ids-history
Revision:	00
Title:		Unfortunate History of Transient Numeric Identifiers
Document date:	2016-07-08
Group:		Individual Submission
Pages:		13
URL:
https://www.ietf.org/internet-drafts/draft-gont-numeric-ids-history-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-numeric-ids-history/
Htmlized:
https://tools.ietf.org/html/draft-gont-numeric-ids-history-00

Abstract:
   This document performs an analysis of the security and privacy
   implications of different types of "numeric identifiers" used in IETF
   protocols, and tries to categorize them based on their
   interoperability requirements and the associated failure severity
   when such requirements are not met.  It describes a number of
   algorithms that have been employed in real implementations to meet
   such requirements and analyzes their security and privacy properties.
   Additionally, it provides advice on possible algorithms that could be
   employed to satisfy the interoperability requirements of each
   identifier type, while minimizing the security and privacy
   implications, thus providing guidance to protocol designers and
   protocol implementers.  Finally, it provides recommendations for
   future protocol specifications regarding the specification of the
   aforementioned numeric identifiers.

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

---

From: Christian Huitema <[email-masked]>
Date: Fri, 8 Jul 2016 18:08:15 +0000

On Friday, July 8, 2016 9:23 AM, Fernando Gont wrote:
> 
> Folks,
> 
> As suggested by a number of folks during the SAAG meeing in Buenos Aires, we
> have submitted the history of flawed numeric IDs as a stand-alone I-D. It is
> available at:

Nice.

> Your input will be very appreciated.

Your draft only provides two examples, IPv4/IPv6 packet identifiers and TCP initial sequence numbers. I would suggest splitting the IPv4 packet identifier and IPv6 fragment identifier in separate cases, and also adding some text at the beginning of each example about the purpose of the identifier.

Also, these two examples do not outline the privacy issues related to other identifier choices. Have you considered adding an history of IPv6 IIDs? This would be a good way to introduce failure modes like "allowing remote scan" or "linkability".

>From a privacy point of view, there are other interesting examples. For example, the initial design of MP-TCP uses a "super-cookie", and the WG is just now trying to mitigate that. There is a similar "super-cookie" issue with the identifiers used to resume sessions in TLS, and it is only getting mitigated in TLS 1.3.

I believe adding more examples would result in a better document.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Jul 2016 20:37:45 +0200

On 07/08/2016 08:08 PM, Christian Huitema wrote:
[....]
>> We believe this information provides good background and motivation
>> for pursuing further work in this area, and learning about errors
>> from the past.
>> 
> Your draft only provides two examples, IPv4/IPv6 packet identifiers
> and TCP initial sequence numbers. 

Yes. We're planning to at least add one more example: DNS TxID... But we
could also add others (e.g., transport protocol numbers).

> I would suggest splitting the IPv4
> packet identifier and IPv6 fragment identifier in separate cases, 

The reason we kept them together was to note how addressing the problem
in the IPv4 case didn't reflect into improvements into the IPv6 case...

Please let us know if you think splitting would be better.

> and
> also adding some text at the beginning of each example about the
> purpose of the identifier.

Will do.

> Also, these two examples do not outline the privacy issues related to
> other identifier choices. Have you considered adding an history of
> IPv6 IIDs? This would be a good way to introduce failure modes like
> "allowing remote scan" or "linkability".

You certainly raise a very good point. Adding a section on IPv6 IIDs
will certainly be a good thing. I'll craft some text and send it n the
list for review.

>> From a privacy point of view, there are other interesting examples.
>> For example, the initial design of MP-TCP uses a "super-cookie",
>> and the WG is just now trying to mitigate that. There is a similar
>> "super-cookie" issue with the identifiers used to resume sessions
>> in TLS, and it is only getting mitigated in TLS 1.3.
> 

Will do. We will certainly add one or both examples of the super cookie
thing. For instance, ow that you mention it, I we talked on the
corridors about the TLS one.

Thanks so much for your comments!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jul 2016 12:14:01 -0700

> > <https://www.ietf.org/internet-drafts/draft-gont-numeric-ids-history-00.txt>
IPv4 IDs are supposed to not be reused within one MDL. See RFC6864 Sec 4.3.

Because IDs aren't used if DF=1, they can (and might be) set to anything
at all (RFC6864 Sec 4.1).

This is important context for this doc.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Jul 2016 21:24:43 +0200

> This is important context for this doc.

Problem here is that, as described in the Silbersack2005 reference,
there were boxes that, despite DF, would fragment anyway. That's why
setting the ID to anything wasn't a "safe" option.

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jul 2016 12:37:23 -0700

> setting the ID to anything wasn't a "safe" option.

That's like saying that it's not safe to generate packets with invalid
IPv4 header checksums because there are devices which ignore them.

The correct action is to fix the behavior of those devices, for many
reasons - not the least of which is that sending packets with DF=1 and
ID=0 has been commonplace as well (but at least that behavior is now
standard).

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Jul 2016 21:45:34 +0200

> IPv4 header checksums because there are devices which ignore them.

It's not. You don't miss much by always setting the Frag ID. Besides
your host doesn't control the misbehaviour of the boxes that are
fragmenting despite DF.

> ID=0 has been commonplace as well (but at least that behavior is now

If you send all packets with the Frag ID=0, and there's a device that
fragments anyway and there's packet loss, you run the risk of getting
all your traffic discarded. OTOH, there doesn't seem to be much of a
drawback in properly setting the frag ID to a non-zero value.

Note: It's not that I love this misbehaving boxes. But me not liking
them does not result in interoperability.

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jul 2016 12:50:06 -0700

On 7/8/2016 12:45 PM, Fernando Gont wrote:
> OTOH, there doesn't seem to be much of a

See RFC6864. It either limits your transmit rate or increases the
probability of mis-reassembled fragments.

This doc should not be directly inconsistent with existing standards.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Fri, 8 Jul 2016 21:55:21 +0200

> probability of mis-reassembled fragments.

Well, we're setting DF anyway, so... why should setting the ID be worse
than setting it to zero?

> This doc should not be directly inconsistent with existing standards.

It is not meant to. Please flag offending text and/or suggest text where
we could be doing better -- I'd be pleased to improve the doc.

Thanks!

Cheers,

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jul 2016 12:59:47 -0700

> Well, we're setting DF anyway, so... why should setting the ID be worse
It's fine to document setting DF as incorrect behavior.

Anything else is a waste of time to discuss.

This doc should not discuss setting the IPv4 ID in ways that are not
consistent with RFC6864, just as it should also be compatible with
existing standards for IPv6.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 9 Jul 2016 12:28:25 +0200

Hi, Joe,

> This doc should not be directly inconsistent with existing standards.

Our document does not really mention the case of setting the Frag ID
when MF=0... so it's not really being inconsistent with existing
standards (as far as I can see).

That said, from a completeness point of view, I guess we could note the
spec update performed by RFC6864.

How about something like:

February 2013:
    [RFC6864] updates [RFC0791] such that the Identification value is
    only meaningful when DF=0. This eliminates e.g. information leakage
    attacks when the corresponding traffic is not fragmented. However,
    [RFC6864] does not introduce any security and privacy
    considerations for setting the Identification field.

?
(please suggest tweaks if necessary)

P.S.: This I-D aside, I don't think setting the ID to non-zero for DF ==
0 limits the data rate: compliant boxes will not fragment the packets
anyway, so for them this is the same as setting the ID to 0. For
non-compliant boxes that do fragment packets when DF=1, you reduce the
chances of frag id collisions at the receiving end...

Thanks!

Cheers,

---

From: Programa STIC <[email-masked]>
Date: Sun, 10 Jul 2016 15:25:51 -0300

Hello

First of all, I'd like to point out that the I-D we are discussing is an
historical account of security & privacy issues derived from
specification or implementation of dynamically generated numeric ids.
It is not a normative document.

So, while context is relevant and RFC6864 should be cited because it is
pertinent, that does not change the fact that the IP ID field was abused
for attacks with varying impact prior to 2013.

Moving on to the matter being discussed:

> (please suggest tweaks if necessary)

After careful reading, I believe RFC 6864 still does not address the
information leakage problem.

Section 4.1 says:

" >> Originating sources MAY set the IPv4 ID field of atomic datagrams
      to any value."

which means that an implementation may still set the ID field to the
value of a monotonically increasing global counter, thus leaking
information while being in complaint with RFC 6864.

>From the security & privacy perspective, a more sane specification would
have been:

 " >>> Originating source MUST set the IPv4 ID field of atomic datagrams
to 0"

That would ensure that atomic fragments don't leak information in their
ID field. I understand there may be interoperability issues with
existing equipment if such text was used instead but those issues
weren't avoided by letting implementations use "any" value either.

Furthermore, section 4.3 of RFC 6864 did not change the following
specification:

">> Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
      values within one MDL for a given source address/destination
      address/protocol tuple."

However, in the context of the I-D about predictable ids the above
paragraph underspecificies the desired behavior, leaving it open for an
implementation to generate values for the IP ID field using an algorithm
that renders the endpoints vulnerable to off-path attacks.

It is also worth nothing that Section 7 ("Security considerations") of
RFC6864 does mention the possible introduction of a covert channel in
making the value of the IP ID field meaningless for atomic datagrams.
The last paragraph of the same section recognizes the existence of a
side channel that leaks information and the possibility for a given
implementation to address one instance of possible attacks but does not
provide explicit guidance on how to do so.

https://tools.ietf.org/html/rfc6864#page-16

In my opinion, this discussion highlights the value and the need for a
document such as
https://www.ietf.org/id/draft-gont-numeric-ids-generation-00.txt in
which guidance and specific algorithms are proposed to avoid known
problems in the generation of values for id fields.

-ivan

---

From: Joe Touch <[email-masked]>
Date: Sun, 10 Jul 2016 22:47:20 -0700

> (please suggest tweaks if necessary)

    [RFC6864] updates [RFC0791] such that the IPv4 Identification value is
    only meaningful when DF=0. This allows nonfragmented/nonfragmentable traffic
    ('atomic', per that RFC) to use arbitrary ID values including values that 
    repeat within 2MSL. Use of uninteresting fixed ID values for atomic traffic
    (e.g., ID=0) eliminates information leakage
    attacks for that traffic. However,
    [RFC6864] does not introduce any new security and privacy
    considerations for setting the Identification field.

> 0 limits the data rate: 

RFC6994 explains what happens if the packet is non-atomic, i.e., it is
susceptible to reassembly errors if the ID repeats within an IP flow
(src, dst, next proto) within the amount of reordering experienced.

The limit is a function of the amount of reordering, which can depend on
the data rate, e.g., if reordering is the result of fixed time delays
between multiple paths.

> compliant boxes will not fragment the packets
> anyway,
That's for DF=1.

>  so for them this is the same as setting the ID to 0. For

If you really meant "setting the ID for DF=1/MF=0", i.e., setting the ID
on atomic packets, then see above- yes, there is a limit to reuse of
those IDs if you intend that they are useful for reassembly --
regardless of whether that's for compliant processing of DF=0 or
DF=1/MF=1 (non-atomic) or for non-compliant processing of DF=1/MF=0
(atomic).

---

From: Fernando Gont <[email-masked]>
Date: Mon, 11 Jul 2016 12:54:13 +0200

Hi, Joe,

>     considerations for setting the Identification field.

I'm fine with the above text. However, the part that says:
     "Use of uninteresting fixed ID values for atomic traffic
     (e.g., ID=0) eliminates information leakage
     attacks for that traffic."

seems misleading. A host could still set the ID with an algorithm that
leaks information. That is, RFC6864 still leaves this unspecified,
because it doesn't say "set it to 0 when DF=1".

> (src, dst, next proto) within the amount of reordering experienced.

NOt just reordering, but also packet loss. If a fragment gets lost, then
that Frag ID is trashed for 60 secs.

> DF=1/MF=1 (non-atomic) or for non-compliant processing of DF=1/MF=0

I meant that, yeS. In that case, from an interoperability pov, setting
the ID regardless of DF will still be better than setting it to a
constant value. If the packet does not get fragmented, no improvements
or drwbacks. But if it does get fragmented, you'll certainly have lower
probability of collisions by setting the ID to a different value for
each packet than setting it to a constant value (e.g., "0").

Setting it to a constant value essentially guarantees to if the packet
is non-compliant-ly fragmented en-route, there will be a frag id collision.

So I don't see the drawback of just always setting the Frag ID,
regardless of DF.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Jul 2016 17:09:22 -0700

> because it doesn't say "set it to 0 when DF=1".
It is 6864 which permits the use of a non-varying value when DF=0 and
not already source fragmented.

Yes, given this doc doesn't introduce new info, it might be OK to drop
that, though.

(note - that does beg the rationale for this draft in the first place.
there seems no utility in merely documenting the history of the mistakes
people have made per se)

> that Frag ID is trashed for 60 secs.

6864 allows reuse within the expected reordering interval. Note that
*expected* reordering is not the actual; presumably, most actual
reordering would be smaller.

>>> compliant boxes will not fragment the packets
and all of IPv6...

> or drwbacks
> .
It has a cost, though - you should not reuse those IDs within your
expected max reordering interval. That, coupled with the size of the ID
field, sets a limit on packet generation.

If the packets are atomic, there is no such limit *because* the ID field
is meaningless.

>  . But if it does get fragmented, you'll certainly have lower
Any device that ignores the DF=1 bit might also ignore the ID and
overwrite it. All bets are off as to what it is doing.

And there is zero utility in documenting noncompliant behavior of this
sort unless it is first aimed at correcting that as a bug.

> is non-compliant-ly fragmented en-route, there will be a frag id collision.

Only if the fragments are also reordered, FWIW.
> So I don't see the drawback of just always setting the Frag ID,

It limits your effective throughput, which is why the need to do so was
deprecated in RFC6864.

Joe

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Jul 2016 01:09:31 +0000

On Monday, July 11, 2016 5:09 PM, Joe Touch wrote:
> ...

Actually, during the previous presentation in SAAG, there was a clear consensus that documenting past mistakes *is* interesting.

OTOH, the draft needs to document something else besides IP and TCP issues. Otherwise, the draft seems to be picking on TCP-IP. Plus, if the point is to show that many people are making the same mistakes, then the draft should have a variety of examples.

-- Christian Huitema

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Jul 2016 20:10:24 -0700

> Actually, during the previous presentation in SAAG, there was a clear consensus that documenting past mistakes *is* interesting.

To what end, other than consuming cycles?

If there's a broader purpose, more information is needed (e.g., whether
each issue is a incorrect to the spec, highlights a spec ambiguity, or
is correct to spec but creates a vulnerability anyway).

E.g., see RFC2525

> OTOH, the draft needs to document something else besides IP and TCP issues. Otherwise, the draft seems to be picking on TCP-IP. Plus, if the point is to show that many people are making the same mi…

Multiple examples does not provide information unless there's a pattern
(see above).

Joe

---

From: Programa STIC <[email-masked]>
Date: Tue, 12 Jul 2016 03:43:21 -0300

> E.g., see RFC2525

RFC 2525 is specific to TCP problems only. What we are trying to point
out is that there is a type of problem, namely the use naive/weak
algorithms to generate values for IDs fields in various protocols, that
ends up creating security and/or privacy issues.

>> OTOH, the draft needs to document something else besides IP and TCP
>> issues. Otherwise, the draft seems to be picking on TCP-IP. Plus,
>> if the point is to show that many people are making the same
>> mistakes, then the draft should have a variety of examples.
> 
> Multiple examples does not provide information unless there's a
> pattern (see above).
> 
> Joe
> 

There is a pattern. The same problem re-occured at different working
groups and network layers over 30+ years. Off the top of my head:

TCP ISN, DNS TxID, ONC RPC XID, IPv4 IP ID, IPv6 FragID, IPv6 IIDs,
NetBIOS NBNS TransactionID, IKE fragmentation ID, RTP sequence number,
NFS file handles.

Documenting past mistakes and showing that the same issue appeared over
and over was deemed useful to justify the need for a set of consistent
rules that provide guidance for the use of dynamically generated values
in ID fields in ways that minimize security & privacy risk.

"Those who don't know history are doomed to repeat it."
- Edmund Burke

cheers,

-ivan

> _______________________________________________ saag mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/saag
> 

-- 
Programa de Seguridad en TIC
Fundación Dr. Manuel Sadosky
Av. Córdoba 744 Piso 5 Oficina I
TE/FAX: 4328-5164

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Jul 2016 08:07:54 +0100

> could also add others (e.g., transport protocol numbers).

Are there any examples from application-level protocols that work here?

I'm not immediately thinking of any, but suspect it would help the 
utility of the document's goal as pedagogy to include an example from 
that part of the stack, if possible.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Fernando Gont <[email-masked]>
Date: Tue, 12 Jul 2016 11:06:49 +0200

On 07/12/2016 05:10 AM, Joe Touch wrote:
>>> ... (note - that does beg the rationale for this draft in the
>>> first place. there seems no utility in merely documenting the
>>> history of the mistakes people have made per se)
>> Actually, during the previous presentation in SAAG, there was a
>> clear consensus that documenting past mistakes *is* interesting.
> 

"those who ignore history are doomed to repeat it".

> If there's a broader purpose, more information is needed (e.g.,
> whether each issue is a incorrect to the spec, highlights a spec
> ambiguity, or is correct to spec but creates a vulnerability
> anyway).

Will clarify this in the next rev. Thanks for the input!

Cheers,

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Jul 2016 11:37:18 +0200

> "those who ignore history are doomed to repeat it".

cf post by watson ladd

---

From: Programa STIC <[email-masked]>
Date: Tue, 12 Jul 2016 10:45:21 -0300

> that part of the stack, if possible.

Predictable session IDs in the web app session level have plagued web
apps and frameworks. Use of predictable numeric IDs in  URL query string
parameters have cause a lot of issues too, specially in web applications
with authentication but without authorization.

I am not sure we want to include examples of web app layer stuff, seem
like opening another big pandora's box

-ivan

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2016 07:53:01 -0700

> "those who ignore history are doomed to repeat it".

The problem is that this is repeating history. At least from 2009.

Joe

---

From: Dave Crocker <[email-masked]>
Date: Tue, 12 Jul 2016 16:13:24 +0100

> like opening another big pandora's box

attending to strings that might be problematic by helping pervasive 
monitoring at one layer of the stack is not very useful if the same 
problem is ignored at another layer.

this sort of privacy concern needs to receive (forgive the pun) pervasively.

it's a version of the basic lesson of interoperability, which teach that 
all components in the sequence have to conform to all of the same 
protocol conventions.  the version here is that seeking meaningful 
privacy means attending to all occurrences of information that might 
enable identifying an actor.

d/

-- 

   Dave Crocker

---

From: Programa STIC <[email-masked]>
Date: Tue, 12 Jul 2016 12:26:07 -0300

Hello Joe

> The problem is that this is repeating history. At least from 2009.

Can you elaborate?

Is there a document already detailing the security and privacy problems
of using predictable values in numeric id fields in many network protocols?

-ivan

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2016 16:38:36 -0000

>"those who ignore history are doomed to repeat it".

"History repeats itself, first as tragedy, then as farce."

R's,
John

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2016 10:37:48 -0700

>> > The problem is that this is repeating history. At least from 2009.

I'm referring to the general process of generating documents that
describe "existing deployment" problems without committing to whether
they are buggy/incorrect implementations.

> of using predictable values in numeric id fields in many network protocols

There are more than a few that already deal with this issue for host
identification.

Joe

---

From: Programa STIC <[email-masked]>
Date: Tue, 12 Jul 2016 16:39:04 -0300

> they are buggy/incorrect implementations.

Sorry I am not understandin your point.

We have split an original I-D in 3 as suggested at IETF95:

- One is informational and describes existing problems in various
protocols and known attacks that exploited those problems.

- One seeks to be BCP and provides specific algorithms that generate
numeric ids taking into consideration security, privacy and
interoperability issues. It provides guidance to protocol designers and
implementers.

- One seeks to update RFC 3552 to indicate that authors of RFCs
specifying numeric id fields with dynamically generated values should
consider the (above) BCP to select algorithms that provide proper
balance between interop and security & privacy.

Is your opinion the the first document of the list above (which is what
originated this thread) should not exist?

> There are more than a few that already deal with this issue for host

Could you please provide the corresponding references?

thanks,
-ivan

---

From: Paul Lambert <[email-masked]>
Date: Tue, 12 Jul 2016 20:54:22 +0000

>Actually, during the previous presentation in SAAG, there was a clear
>consensus that documenting past mistakes *is* interesting.

Yes - this is interesting, especially if there can also be clarity on
action items to fix identified problems.

>issues.

One of my favorite Œprivacy issues' is in IPsec RFC 4301:
	"Search the SAD for a match on the combination of SPI, destination
address, and source address.²

IMHO the binding of the security association explicitly to the src/dst IP
addresses creates NATing problems and prevents interesting onion routing
like implementations that would hide the end addresses.  For best common
practice for any security protocol there should be no explicit binding of
visible addresses to the identifiers for encrypted information.

Paul

---

From: Paul Lambert <[email-masked]>
Date: Tue, 12 Jul 2016 21:12:13 +0000

>issues. Otherwise, the draft seems to be picking on TCP-IP.

While not an IETF specification, the NIST SP 800-56A Recommendation for
Pair-Wise Key Establishment Schemes is indicative of mistakes in protocol
design that institutionalize privacy issues.  Specifically, the document
provides a detailed list of possible key exchanges - none of which protect
the long term identity (static key) from third party observation.  For
some reason, the specification for all proposed key exchanges sends the
static keys first.  Best practice would suggest that passive observation
of long term identities (the static keys) could be prevented by always
sending the ephemeral keys first and then encrypting the transfer of the
static keys (which are often embodied in a certificate).

Paul

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2016 14:14:58 -0700

> action items to fix identified problems.

Having these as separate documents doesn't help that process.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2016 14:25:47 -0700

> originated this thread) should not exist?

The problem is in the first doc- you're assuming that the problem is
fixed by using different agls (the second doc) or in how protocols are
spec'd (the third doc), when you haven't explained whether those
problems are implementation errors, specification ambiguities, or
specification errors that give rise to the exploits described.

Joe

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Jul 2016 15:23:38 -0400

Paul,

the use of the 5-tuple you cited 4301 is needed to enforce a security 
policy based on those values. This was very common practice in firewall 
security policies in the time frame that 4301 was generated, and IPsec 
was striving to provide crypro-enforced security features analogous to 
what was available in firewalls.

yes, using this approach does cause problems with NATs, but at that time 
NATs were still viewed as evil ;-). Onion routing compatibility was not 
a goal for IPsec.

Steve

> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 12 Jul 2016 19:10:46 +0200

> Are there any examples from application-level protocols that work here?

I don't remember thinking about application-level protocol examples. But
Ivan mentioned NFS file handles....

We'll try to include some of these in the next rev of the document.

Thanks!

Cheers,

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Jul 2016 19:57:35 +0200

> We'll try to include some of these in the next rev of the document.

NFS file handles sounds good.

Also note that RFCs 5321/5322 produce a 'Received' header field that 
often contains the IP address and/or domain name of the previous-hop 
SMTP client.  At the start of the transmission sequence, that could be 
the user's host identifier....

d/

-- 

   Dave Crocker