Re: WiFi - login page redirection not working

[Jimmy Hess]

On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish 
wrote:


> Two points with this problem: 1)Is there a "non client" solution to the
> problem of the WiFi login notification not showing up on the clients after
> connecting to the WiFi network?
>

A  Captive portal  embedding WispR  XML data
for connections from browsers/OSes that request a test page upon network
access.
https://stackoverflow.com/questions/3615147/how-to-create-wifi-popup-login-page

However if WPA2 authentication is not method used for access,  then network
traffic is
vulnerable and not secured.

AP solutions that are non-standard being a "Non client" solution and using
"Open Wireless" mode SSIDs are likely so deficient in security as to be
an unreasonable risk for users to actually connect to.


> Second, anything to be done from the AP to show the landing page even if
> the page requested is HTTPs?
>

If TLS  would somehow allow you to redirect or create a HTTPS connection
from
a domain name that is not yours, then this could obviously be exploited for
attacks.

--
-JH

WiFi - login page redirection not working

[Ramy Hashish]

Good day all,

A lot have been said on this topic, however I want to make sure I am not
missing something.

Two points with this problem: 1)Is there a "non client" solution to the
problem of the WiFi login notification not showing up on the clients after
connecting to the WiFi network?

Second, anything to be done from the AP to show the landing page even if
the page requested is HTTPs?

Thanks,

Ramy

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/29/2017 07:16 PM, William Herrin wrote:
There's no "must" standard for the format of bounce message, deferred 
bounces are still a thing and mail gets auto-forwarded to addresses which 
bounce (that is, bounce from an address different than the one you sent to).


Agreed.  I wish that more software would use the well defined Delivery 
Status Notification and Message Disposition Notifications.  (RFC 6553)


Without something like VERP to encode the original recipient in the return 
address, the percentage of bounces your list successfully processes each 
month will slowly but steadily decline.


I think it's entirely possible to teach MLMs about the most common forms 
of bounces (DSNs).  But it will quickly get into a game of diminishing 
returns.  Especially if the bounce (because it's not going to be the 
well known DNS format) goes out of it's way to hide something.  In that 
case, the only thing that you could count on (that I'm aware of) is 
something like VERP.


I wonder if SMTP's ORCPT parameter to the RCPT command would cross 
forwarders.  (I'm not holding my breath.)


Aside:  I'm quite interested in discussing the the following reply, but 
I suspect it's going to be a bit of a rabbit whole.  Is such a 
discussion appropriate for NANOG?  (I'll assume that a lack of reply 
indicates that the discussion is better had elsewhere.)


I could not disagree with you more. It's relatively easy to design and 
implement a system which allows the originating MUA and MTA to offer proof 
of authority to act on behalf of a given email address. Though possible, 
systems which would allow intermediate mail handlers to generate proof of 
authority to handle a message alleged to originate from a particular 
address don't especially exist and would be much more complex. Systemic and 
computational complexity is a very practical difference between the two 
situations.


I feel like SPF & DKIM (at least partially) address the former scenario. 
 -  I think that SPF and DKIM-ATPS can (at least partially) address the 
latter.  With the latter assuming some sort of established business 
relationship between the originating and intermediary parties.




--
Grant. . . .
unix || die

Re: Incoming SMTP in the year 2017 and absence of DKIM

[William Herrin]

On Wed, Nov 29, 2017 at 5:50 PM, John Levine  wrote:
>
> In article <3677d101-3874-b8e4-87b3-37e4dd870...@tnetconsulting.net> you
write:
> >> Normal lists put their own bounce address in the
> >> envelope so they can handle the bounces, so their own SPF applies.
> >
> >Yep.  V.E.R.P. is a very powerful thing.  (B.A.T.V. is an interesting
> >alternative, but I never messed with it.)
>
> VERP helps identify the bouncing party, but list bounce handling works
> fine without it.

Not so much, no.

There's no "must" standard for the format of bounce message, deferred
bounces are still a thing and mail gets auto-forwarded to addresses which
bounce (that is, bounce from an address different than the one you sent to).

Without something like VERP to encode the original recipient in the return
address, the percentage of bounces your list successfully processes each
month will slowly but steadily decline.

Broken rDNS is just broken, since there's approximately no reason ever
> to send from a host that doesn't know its own name.  Broken SPF may or
> may not be an issue since there are lots of legit ways to send mail
> that SPF can't describe.
>

+1


>P.S.  I'm strongly of the opinion that if a MLM alters the message in
> >ANY capacity, that it is actually generating a new message.  Thus the
> >MLM is the new author.  It's just using content strongly based on emails
> >that came into it.  -  But that's a different discussion that lasted
> >days on the mailman mailing list.
>
> It's an interesting theological argument but it makes little practical
> difference.
>

I could not disagree with you more. It's relatively easy to design and
implement a system which allows the originating MUA and MTA to offer proof
of authority to act on behalf of a given email address. Though possible,
systems which would allow intermediate mail handlers to generate proof of
authority to handle a message alleged to originate from a particular
address don't especially exist and would be much more complex. Systemic and
computational complexity is a very practical difference between the two
situations.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM

[valdis . kletnieks]

On Wed, 29 Nov 2017 13:46:05 -0800, Michael Thomas said:

> Apparently the levine unit is hearing things again because nobody --
> least of all me -- has
> said anything about arc.

I believe it was a pre-emptive statement.


pgp2H7Fy1I06i.pgp
Description: PGP signature

Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM

[Michael Thomas]

On 11/29/2017 01:11 PM, John Levine wrote:


PPS: Please spare us pontification about why ARC can't possibly work
unless you're prepared to cite section numbers in the ARC spec
supporting your argument.


Apparently the levine unit is hearing things again because nobody -- 
least of all me -- has

said anything about arc.

Mike

Subnet being blocked by Level3 due to prior owner's misuse

[Brock Tice]

We have a subnet that used to belong to someone else. One of our
business customers that was recently moved to that subnet is being
blocked from accessing one of their supplier's web site that's hosted by
Level3.

Our attempts to work through the supplier to resolve the issue have not
worked as they are not aware of what's happening at that level. Our
other attempts to resolve this have not worked.

Would someone from Level3 be able to help resolve this off-list, or does
someone have the appropriate contact information?

Thanks,
  --Brock

Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM

[Michael Thomas]

On 11/29/2017 03:00 PM, Grant Taylor via NANOG wrote:

On 11/29/2017 03:46 PM, Michael Thomas wrote:
You know what the original header was via the signature. You can take 
the delta of the current subject line and remove any additions and 
validate the signature. Whether you're happy with the additions is a 
different concern,


Are you referring to the optional z DKIM-Signature tag?

Or are you referring to brute forcing what the subject was in order to 
derive the delta of the current subject?  This would be compounded by 
any number of other changes to (over)singed headers / body portion.


If I were constructing a spam filter out of it, I'd give a lot of 
prejudice to anything added, but that's outside of

what you can do within the bounds of the spec.


*If* the z tag was included in the DKIM-Signature header, I can see 
how this would work and I agree with your distrust of said additions / 
alterations.




Yes, with the z=

Mike

Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/29/2017 03:46 PM, Michael Thomas wrote:
You know what the original header was via the signature. You can take 
the delta of the current subject line and 
remove any additions and validate the signature. Whether you're happy 
with the additions is a different concern,


Are you referring to the optional z DKIM-Signature tag?

Or are you referring to brute forcing what the subject was in order to 
derive the delta of the current subject?  This would be compounded by 
any number of other changes to (over)singed headers / body portion.


If I were constructing a spam filter out of it, I'd give a lot of 
prejudice to anything added, but that's outside of

what you can do within the bounds of the spec.


*If* the z tag was included in the DKIM-Signature header, I can see how 
this would work and I agree with your distrust of said additions / 
alterations.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Incoming SMTP in the year 2017 and absence of DKIM

[John Levine]

In article <11e9c18dac053c4bb91b95a4993c1...@mail.dessus.com> you write:
>
>Not old enough to have had an Executive Secretary processing your incoming 
>snail-mail before it gets to you?

Probably about the same age as you, but I hope that after 50 years of
e-mail we have figured out that the parallels with paper mail are
imperfect.  The e-mail envelope is a metaphor, you know.

R's,
John

Re: Incoming SMTP in the year 2017 and absence of DKIM

[John Levine]

In article <3677d101-3874-b8e4-87b3-37e4dd870...@tnetconsulting.net> you write:
>> Normal lists put their own bounce address in the 
>> envelope so they can handle the bounces, so their own SPF applies.
>
>Yep.  V.E.R.P. is a very powerful thing.  (B.A.T.V. is an interesting 
>alternative, but I never messed with it.)

VERP helps identify the bouncing party, but list bounce handling works
fine without it.  What matters is that it's the list's address in the
envelope, not the message author.  BATV works OK (I should know, I
invented it) but it has its false positives.

>I'm saying that I've heard arguments over the last 15 years from people 
>that (FC)rDNS and SPF (independently) are things that will break some 
>portion of email.

Broken rDNS is just broken, since there's approximately no reason ever
to send from a host that doesn't know its own name.  Broken SPF may or
may not be an issue since there are lots of legit ways to send mail
that SPF can't describe.

R's,
John

>P.S.  I'm strongly of the opinion that if a MLM alters the message in 
>ANY capacity, that it is actually generating a new message.  Thus the 
>MLM is the new author.  It's just using content strongly based on emails 
>that came into it.  -  But that's a different discussion that lasted 
>days on the mailman mailing list.

It's an interesting theological argument but it makes little practical
difference.

Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM

[Michael Thomas]

On 11/29/2017 02:40 PM, Grant Taylor via NANOG wrote:

On 11/29/2017 03:24 PM, Michael Thomas wrote:
Message footers and subject lines can be dealt with. That's already 
been proven within the current DKIM spec.


Please humor my ignorance and explain how a subject line (which is 
(over)signed) can be dealt with in the current DKIM spec?


I get how footers can be dealt with, read appended.  At least as long 
as DKIM only signs a given amount of the (original) body. (Though HTML 
(read: MIME structures) can complicate this.)  -  Or are you referring 
to something else?




You know what the original header was via the signature. You can take 
the delta of the current subject line and
remove any additions and validate the signature. Whether you're happy 
with the additions is a different concern,


If I were constructing a spam filter out of it, I'd give a lot of 
prejudice to anything added, but that's outside of

what you can do within the bounds of the spec.

Mike

Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/29/2017 03:24 PM, Michael Thomas wrote:
Message footers and subject lines can be dealt with. That's already been 
proven within the current DKIM spec.


Please humor my ignorance and explain how a subject line (which is 
(over)signed) can be dealt with in the current DKIM spec?


I get how footers can be dealt with, read appended.  At least as long as 
DKIM only signs a given amount of the (original) body.  (Though HTML 
(read: MIME structures) can complicate this.)  -  Or are you referring 
to something else?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM

[Michael Thomas]

On 11/29/2017 01:11 PM, John Levine wrote:

In article <1d458e76-ab61-db28-79cb-6aabcab4f...@mtcc.com> you write:

I've been saying for years that it should be possible to create the
concept of DKIM-friendly mailing lists. ...

I suppose, if your users are OK with no subject tags, message footers,
or any of the other cruft that list users have taken for granted for
the past 30 years.



Message footers and subject lines can be dealt with. That's already been 
proven within

the current DKIM spec.

Mike

RE: Incoming SMTP in the year 2017 and absence of DKIM

[Keith Medcalf]

Not old enough to have had an Executive Secretary processing your incoming 
snail-mail before it gets to you?

The "envelope" in which a letter arrived is just as important as the letter 
itself and contains valuable information that is duplicated in e-mail -- the 
postmark (received headers), the return address (mail from); and, the delivery 
address (mail to).

It was an offense to discard the envelope in which correspondence arrived since 
it is used to determine the validity of the snail mail.

Current e-mail clients are comparable to having a secretary that throws out the 
envelope and snips off most of the inside addressing information and delivers 
only the heavily redacted letter so that no determination of its validity is 
possible.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of John Levine
>Sent: Wednesday, 29 November, 2017 14:28
>To: nanog@nanog.org
>Subject: Re: Incoming SMTP in the year 2017 and absence of DKIM
>
>In article <20171129183535.gb18...@ucsd.edu> you write:
>>As I see it, the problem isn't with DKIM, it's with the
>>implementation of DMARC and other such filters.  Almost all
>>of them TEST THE WRONG FROM ADDRESS.  They compare the Author's
>>address (the header From: line) instead of the Sender's address,
>
>Sigh.  I have my differences with the people who designed DMARC but
>they are not stupid and they really do understand the relevant RFCs.
>Some of them even wrote some of those RFCs.
>
>The reason they look at the From: line is that's the one recipients
>see.  The Sender: header was a nice idea but in practice, it's not
>useful.
>
>R's,
>John

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/29/2017 02:13 PM, John Levine wrote:
A mailing list sending with bad rDNS or bad SPF is a pretty cruddy 
mailing list.


s/mailing list sending/sending server/

Agreed.

Normal lists put their own bounce address in the 
envelope so they can handle the bounces, so their own SPF applies.


Yep.  V.E.R.P. is a very powerful thing.  (B.A.T.V. is an interesting 
alternative, but I never messed with it.)


No idea why you think rDNS for a list's MTA is any harder than anyone 
else's MTA.


I don't.

I'm saying that I've heard arguments over the last 15 years from people 
that (FC)rDNS and SPF (independently) are things that will break some 
portion of email.  -  I believe that these are simply technologies that 
the email industry has adopted and now considers to be Best Practice, if 
not actual requirements that MUST be done.


IMHO, Mailing List Managers are simply a different form of MUA that 
utilizes the same email infrastructure (MTAs.)  Thus, MLMs are subject 
tot he same requirements as "individual email" (as referred to earlier.)




--
Grant. . . .
unix || die

P.S.  I'm strongly of the opinion that if a MLM alters the message in 
ANY capacity, that it is actually generating a new message.  Thus the 
MLM is the new author.  It's just using content strongly based on emails 
that came into it.  -  But that's a different discussion that lasted 
days on the mailman mailing list.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Incoming SMTP in the year 2017 and absence of DKIM

[John Levine]

In article <20171129183535.gb18...@ucsd.edu> you write:
>As I see it, the problem isn't with DKIM, it's with the
>implementation of DMARC and other such filters.  Almost all
>of them TEST THE WRONG FROM ADDRESS.  They compare the Author's
>address (the header From: line) instead of the Sender's address,

Sigh.  I have my differences with the people who designed DMARC but
they are not stupid and they really do understand the relevant RFCs.
Some of them even wrote some of those RFCs.

The reason they look at the From: line is that's the one recipients
see.  The Sender: header was a nice idea but in practice, it's not
useful.

R's,
John

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/29/2017 11:35 AM, Brian Kantor wrote:

As I see it, the problem isn't with DKIM,


I don't think DKIM is (the source of) /the/ problem per say.  Rather I 
think it's a complication of other things (DMARC) that interact with DKIM.


it's with the 
implementation of DMARC and other such filters.  Almost all 
of them TEST THE WRONG FROM ADDRESS.  They compare the Author's 
address (the header From: line) instead of the Sender's address, 
(the SMTP Mail From: transaction or Sender: header line).


I believe it's more than just the implementation.  The DMARC 
specification specifically calls out the RFC 5322 From: header.


Further, RFC 7489, Appendix A, § 3 speaks directly to this.

If the filter checked the Sender address of mail instead of the 
Author address, mailing lists wouldn't be broken!


Perhaps.  However I fear we would be facing an entirely new type of spam 
that used spoofed From: headers and perfectly legitimate Sender: headers 
(that also match the RFC 5321 SMTP FROM address.)  See RFC 7489 § A.3.1




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Incoming SMTP in the year 2017 and absence of DKIM

[John Levine]

In article <85393a12-a51f-6722-4171-118919fcc...@mtcc.com> you write:
>The real problem with large enterprise that we found, however, is that 
>it was really hard to track down every 25 year
>old 386 sitting in dusty corners that was sending mail directly instead 
>of through corpro servers to make certain
>that everything was signed that should be signed. Maybe that's gotten 
>better in the last 15 years, but I'm not too hopeful.

No kidding.  That's why you publish a DMARC policy record that says
don't treat my mail any differently, but please send me summary
reports about it.  This lets you see where mail with your From: domain
is coming from, to track down all those dusty servers.  Once you've
found them all, then you can decide whether publishing a policy is
likely make things better or worse.

You'll also find a whole lot of Chinese botnets that send out spam
with random return addresses including yours, but they're not hard to
tell apart.

R's,
John

Re: Incoming SMTP in the year 2017 and absence of DKIM

[John Levine]

In article <88a1ae22-a5c1-dc46-caa7-cca813109...@tnetconsulting.net> you write:
>  - Requiring Reverse DNS
>  - SPF
>
>I'm not commenting about the viability of these things, just that they 
>are fairly well accepted and that they can trivially break mailing lists.

A mailing list sending with bad rDNS or bad SPF is a pretty cruddy
mailing list.  Normal lists put their own bounce address in the
envelope so they can handle the bounces, so their own SPF applies.

No idea why you think rDNS for a list's MTA is any harder than anyone
else's MTA.

R's,
John

Re: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM

[John Levine]

In article <1d458e76-ab61-db28-79cb-6aabcab4f...@mtcc.com> you write:
>I've been saying for years that it should be possible to create the 
>concept of DKIM-friendly mailing lists. ...

I suppose, if your users are OK with no subject tags, message footers,
or any of the other cruft that list users have taken for granted for
the past 30 years.

The people who brought us DMARC have a new anti-DMARC thing called
ARC that is intended to help recipients guess whether a message with
a broken signature came through a mailing list.  It's a kludge, but
since it's a kludge that Gmail has already implemented, you'll be
seeing more of it.

Returning to the original question, if a message has no DKIM
signature, that doesn't say anything particularly bad, but it does
mean that the sending IP is your main bit of info to decide whether
it's mail you want, which has issues of its own.

R's,
John

PS: details here https://dmarc.org/resources/specification/

PPS: Please spare us pontification about why ARC can't possibly work
unless you're prepared to cite section numbers in the ARC spec
supporting your argument.

Re: tracking TCP session hop by hop

[Yifeng Zhou]

Thank you all for the reply!

I think traceroute/tcptraceroute is a good way to track tcp session as we
can use same 5 tuple as normal TCP does.

Bill brought up an interesting point about MPLS and Ethernet, I give it a
bit of think and here's what i can tell, please correct me if i'm wrong

for MPLS, everything should be the same prior enter MPLS cloud. At ingress
router, it will push MPLS label (also entropy label if enabled), but it
should be the same for traceroute traffic and actual TCP traffic(we have
same 4 tuple, or 5, including incoming interface on router), so the
label/entropy label should be same. Inside MPLS cloud, normally router will
use mpls label, src, dst ip, port number(or entropy label if enabled) as
hash seed(depends on configuration) to calculate which ECMP path it will
use. Choose member link inside lAG might be another story for non-entropy
enabled MPLS cloud, but we don't really care as they belong to same
IP(layer-3) path, but I think they should be same as well?

Thanks

2017-11-29 9:06 GMT-08:00 William Herrin :

> On Tue, Nov 28, 2017 at 3:48 PM, Yifeng Zhou 
> wrote:
>
>> Is there any way that we can track TCP session hop by hop?
>>
>> Say we have 10 ECMP between A and Z point, what's the easiest way to track
>> specific session is using which path? How we can check between
>> servers(Linux/Unix) and between Routers(Cisco/Juniper etc)?
>>
>
> A TCP connection is uniquely identified by the combination of four
> numbers: The source IP address, the source port, the destination IP address
> and the destination port. You used the word session, but sessions happen
> above TCP in the stack and may use more than one TCP connection.  Every
> packet in the connection contains all four numbers and no packet from any
> other connection contains the same four numbers.
>
> If you want to track the connections, you capture the packets at each
> point in the path (router products have vendor-specific ways of doing this)
> and see which unique sets of the four numbers went through which router and
> router interface.
>
>
> If you want to -test- which path a TCP connection -would- take, Ruairi's
> afore-mentioned tcptraceroute is the way to go. The regular traceroute with
> modern Linux servers also supports the "-T" flag which does the same thing.
> It works just like regular traceroute but uses synthetic TCP SYN packets
> instead of ICMP or UDP packets, allowing the packets to pass firewalls
> which would otherwise block the trace.
>
> Bear in mind that in each case you will likely only see the path taken at
> the IP level. Underlying transits at the Ethernet or MPLS level are
> intentionally invisible to the endpoints.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Brian Kantor]

As I see it, the problem isn't with DKIM, it's with the
implementation of DMARC and other such filters.  Almost all
of them TEST THE WRONG FROM ADDRESS.  They compare the Author's
address (the header From: line) instead of the Sender's address,
(the SMTP Mail From: transaction or Sender: header line).

For personal mail, these are almost always the same, but for
properly-functioning mailing lists, the Author address is the
email address of the person submitting the posting to the mailing
list, and the Sender address is the error-return ("bounce") address
of the mailing list.

If the filter checked the Sender address of mail instead of the
Author address, mailing lists wouldn't be broken!
- Brian


On Wed, Nov 29, 2017 at 10:12:05AM -0800, Michael Thomas wrote:
> I've been saying for years that it should be possible to create the concept
> of DKIM-friendly mailing lists. In such
> a case, you could have your nines. Until then, the best you can hope for is
> the list re-signing the mail and blaming
> the list owner instead.
> 
> Mike

RE: Incoming SMTP in the year 2017 and absence of DKIM

[Keith Medcalf]

In which case neither will they be RFC compliant.

(1) The "inaddr-arpa" ptr from the incoming connection, when resolved, MUST 
result in a set of IP Addresses which includes the original IP Address.

(2) The "name" specified in the HELO/EHLO MUST resolve to an MTA that meets the 
above reverse/forward resolution requirement.

(3) The domain name specified in the envelope-from MUST be resolvable to an MTA 
that meets the above requirement (1) or be empty.

(4) The SPF checking, if done, MUST NOT fail.

(5) The connecting MTA MUST NOT speak when not spoken to (that is, it MUST NOT 
not violate the SMTP chat protocol).

If you dump all connections that are do not meet these requirements, you will 
have eliminated 99% or more of all spam.

DKIM signatures do not really add much at all except prove that the message was 
sent through a server that could calculate a DKIM signature.  It says nothing 
about whether the message is SPAM or not.  99% (or more) of all spam will have 
violated one or more of rules (1) through (5) long before the message contents 
are accepted so that the signature can be verified.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Eric Kuhnke
>Sent: Wednesday, 29 November, 2017 11:19
>To: nanog@nanog.org list
>Subject: Re: Incoming SMTP in the year 2017 and absence of DKIM
>
>Anecdotal experience. I'm subscribed to a lot of mailing lists. Some
>pass
>through DKIM correctly. Others re-sign the message with DKIM from
>their own
>server.
>
>>98% of the spam that gets through my filters, which comes from an IP
>not
>in any of the major RBLs, has no DKIM signature for the domain. My
>theory
>is that it does introduce somewhat of a barrier to spam senders
>because
>they are frequently not in control of the mail server (which may be
>some
>ignorant third party's open relay), nor do they have access to the
>zonefile
>for the domain the mail server belongs to for the purpose of adding
>any
>sort of DKIM record.
>
>
>
>On Wed, Nov 29, 2017 at 10:12 AM, Michael Thomas 
>wrote:
>
>> On 11/29/2017 10:03 AM, valdis.kletni...@vt.edu wrote:
>>
>>> On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said:
>>>
>>> There are quite a few things you can do to get the mailing list
 traversal rate > 90%, iirc.

>>> Only 90% should be considered horribly broken.  Anything that
>makes
>>> it difficult to run a simple mailing list with less that at least
>2 or 3
>>> 9's
>>> is unacceptable.
>>>
>>
>> I've been saying for years that it should be possible to create the
>> concept of DKIM-friendly mailing lists. In such
>> a case, you could have your nines. Until then, the best you can
>hope for
>> is the list re-signing the mail and blaming
>> the list owner instead.
>>
>> Mike
>>
>>

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/29/2017 01:35 PM, Blake Hudson wrote:
Where DKIM/SPF really help is when there's a failure that indicates a 
message has been spoofed.


There are other legitimate things that can break DKIM signatures.  I 
have personally seen changes in content type encoding break a DKIM 
signature.


The message was perfectly valid, and only failed DKIM signature validation.

This is a good indication of phishing and is a 
justified reason to reject or quarantine a message in the interest of 
your employees or subscribers.


As much as I would like to be able to safely reject on DKIM Signature 
validation failure, I don't think that it is safe to do so.


Sometimes these will be config errors, 
but I feel confident telling the sender to take config issues up with 
their service provider.


Hopefully this will bring the perceived problem to someone's attention 
who can hypothetically do something to correct it.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/29/2017 01:17 PM, Michael Thomas wrote:
Remember: if you treat a broken signature better than lack of signature, 
spammers will just insert phony signatures to game you.


So they really are the same.


Yes, they are /effectively/ the same.  However it is possible to 
distinguish between a broken DKIM signature and the lack of a DKIM 
signature.


What you do with that information is up to you.  -  Guidelines suggest 
that you treat them the same.  (Thus them being /effectively/ the same.)


The real problem with large enterprise that we found, however, is that 
it was really hard to track down every 25 year 
old 386 sitting in dusty corners that was sending mail directly instead 
of through corpro servers to make certain 
that everything was signed that should be signed. Maybe that's gotten 
better in the last 15 years, but I'm not too hopeful.


I hear you, and I don't disagree with your sentiments about the 
difficult of the matter.  However, I find it highly suspect that such 
systems ancient are still in use.  There may very well be replacements 
for said systems that are < 20 years old.


Either way, they would still run afoul of things like SPF (unless you 
allow your entire IP space to send email).


There are other security / vulnerability implications of such 
infrastructures.  -  I'd argue that they are motivation enough to 
wrangle these rogue systems.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Chuck Anderson]

On Wed, Nov 29, 2017 at 12:17:57PM -0800, Michael Thomas wrote:
> The real problem with large enterprise that we found, however, is
> that it was really hard to track down every 25 year
> old 386 sitting in dusty corners that was sending mail directly
> instead of through corpro servers to make certain
> that everything was signed that should be signed. Maybe that's
> gotten better in the last 15 years, but I'm not too hopeful.

15 years ago we blocked outbound port 25 except from our campus mail
servers.  That should be SOP by now.  It is fairly easy to look at
firewall logs to find these.

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Blake Hudson]

Eric Kuhnke wrote on 11/29/2017 11:03 AM:

For those who operate public facing SMTPd that receive a large volume of
incoming traffic, and accordingly, a lot of spam...

How much weight do you put on an incoming message, in terms of adding
additional score towards a possible value of spam, for total absence of
DKIM signature?


Spammers can:
    A) Establish domains that use SPF and DKIM as well as anyone else
    B) Use the stolen credentials of legitimate accounts on legitimate 
servers to relay SPAM messages.


So the presence of SPF/DKIM does not reliably indicate whether the 
message is spam or not - only that the sender is "authenticated". The 
lack of optional tech like SPF and DKIM might be used as a heuristic, 
but it's not reliable enough to use in practice in my opinion. I 
wouldn't quarantine or reject messages that are missing these optional 
technology because the take rate isn't high enough.


Where DKIM/SPF really help is when there's a failure that indicates a 
message has been spoofed. This is a good indication of phishing and is a 
justified reason to reject or quarantine a message in the interest of 
your employees or subscribers. Sometimes these will be config errors, 
but I feel confident telling the sender to take config issues up with 
their service provider.

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Michael Thomas]

On 11/29/2017 11:53 AM, Grant Taylor via NANOG wrote:

On 11/29/2017 11:33 AM, Michael Thomas wrote:
A broken DKIM signature is indistinguishable from a lack of a 
signature header.


I'll argue that it's possible to distinguish between the two. 
*However* the DKIM standard states that you should treat a broken DKIM 
signature the same as no DKIM signature.


Remember: if you treat a broken signature better than lack of signature, 
spammers will just insert phony signatures to game you.


So they really are the same.

Not being able to tell if DKIM is in use has been a long standing 
annoyance of mine.


That being said, I think it could be trivial to query for DMARC 
records and deduce things from the existence of the "adkim" option.  
If it's there and set to reject, then there really should be 
DKIM-Signature header for the message. 


I haven't really kept up with dmarc, but its progenitor ssp could give 
you that indication, iirc.


The real problem with large enterprise that we found, however, is that 
it was really hard to track down every 25 year
old 386 sitting in dusty corners that was sending mail directly instead 
of through corpro servers to make certain
that everything was signed that should be signed. Maybe that's gotten 
better in the last 15 years, but I'm not too hopeful.


Mike

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/29/2017 11:03 AM, valdis.kletni...@vt.edu wrote:
Only 90% should be considered horribly broken.  Anything that makes it 
difficult to run a simple mailing list with less that at least 2 or 3 
9's is unacceptable.


There have been a number of things that fall into that category, two of 
which immediately come to mind are:


 - Requiring Reverse DNS
 - SPF

I'm not commenting about the viability of these things, just that they 
are fairly well accepted and that they can trivially break mailing lists.


IMHO, DKIM and DMARC are just the recent additions to that list.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Grant Taylor via NANOG]

On 11/29/2017 11:33 AM, Michael Thomas wrote:
A broken DKIM signature is indistinguishable from a lack of a signature 
header.


I'll argue that it's possible to distinguish between the two.  *However* 
the DKIM standard states that you should treat a broken DKIM signature 
the same as no DKIM signature.


I've come to understand DKIM to be proof /positive/, as in trust 
something when there is a DKIM signature -and- it validates.  Everything 
else defaults to neutral, NOT /negative/.


It's possible that as a heuristic you might be able to divine something 
from lack of signature and the existence of selectors for a domain, but 
afaik there isn't an easy way to query for all of the dkim selectors for 
a domain, and even if there were it would be a pretty sketchy heuristic, 
is my bet.


Not being able to tell if DKIM is in use has been a long standing 
annoyance of mine.


That being said, I think it could be trivial to query for DMARC records 
and deduce things from the existence of the "adkim" option.  If it's 
there and set to reject, then there really should be DKIM-Signature 
header for the message.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: tracking TCP session hop by hop

[Peter Phaal]

On Wed, Nov 29, 2017 at 9:06 AM, William Herrin  wrote:

> On Tue, Nov 28, 2017 at 3:48 PM, Yifeng Zhou 
> wrote:
>
> > Is there any way that we can track TCP session hop by hop?
> >
> > Say we have 10 ECMP between A and Z point, what's the easiest way to
> track
> > specific session is using which path? How we can check between
> > servers(Linux/Unix) and between Routers(Cisco/Juniper etc)?
> >
>
> A TCP connection is uniquely identified by the combination of four numbers:
> The source IP address, the source port, the destination IP address and the
> destination port. You used the word session, but sessions happen above TCP
> in the stack and may use more than one TCP connection.  Every packet in the
> connection contains all four numbers and no packet from any other
> connection contains the same four numbers.
>
> If you want to track the connections, you capture the packets at each point
> in the path (router products have vendor-specific ways of doing this) and
> see which unique sets of the four numbers went through which router and
> router interface.
>
>
> If you want to -test- which path a TCP connection -would- take, Ruairi's
> afore-mentioned tcptraceroute is the way to go. The regular traceroute with
> modern Linux servers also supports the "-T" flag which does the same thing.
> It works just like regular traceroute but uses synthetic TCP SYN packets
> instead of ICMP or UDP packets, allowing the packets to pass firewalls
> which would otherwise block the trace.
>
> Bear in mind that in each case you will likely only see the path taken at
> the IP level. Underlying transits at the Ethernet or MPLS level are
> intentionally invisible to the endpoints.
>
>
In the data center context, enabling sFlow continuously captures packets
from all paths and can be used to trace multi-path packet flows, whether
layer 2 (MLAG/LAG), or layer 3 (ECMP). sFlow reports physical switch ports
and captures Ethernet packet headers, so you can relate paths to MPLS
labels, Ethernet headers, IP headers, TCP/UDP headers, VxLAN tunnels, etc.

The following article provides an example:
http://blog.sflow.com/2017/09/troubleshooting-connectivity-problems.html

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Michael Thomas]

A broken DKIM signature is indistinguishable from a lack of a signature 
header. It's possible that as a heuristic
you might be able to divine something from lack of signature and the 
existence of selectors for a domain, but
afaik there isn't an easy way to query for all of the dkim selectors for 
a domain, and even if there were it would

be a pretty sketchy heuristic, is my bet.

Mike

On 11/29/2017 10:18 AM, Eric Kuhnke wrote:

Anecdotal experience. I'm subscribed to a lot of mailing lists. Some pass
through DKIM correctly. Others re-sign the message with DKIM from their own
server.


98% of the spam that gets through my filters, which comes from an IP not

in any of the major RBLs, has no DKIM signature for the domain. My theory
is that it does introduce somewhat of a barrier to spam senders because
they are frequently not in control of the mail server (which may be some
ignorant third party's open relay), nor do they have access to the zonefile
for the domain the mail server belongs to for the purpose of adding any
sort of DKIM record.



On Wed, Nov 29, 2017 at 10:12 AM, Michael Thomas  wrote:


On 11/29/2017 10:03 AM, valdis.kletni...@vt.edu wrote:


On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said:

There are quite a few things you can do to get the mailing list

traversal rate > 90%, iirc.


Only 90% should be considered horribly broken.  Anything that makes
it difficult to run a simple mailing list with less that at least 2 or 3
9's
is unacceptable.


I've been saying for years that it should be possible to create the
concept of DKIM-friendly mailing lists. In such
a case, you could have your nines. Until then, the best you can hope for
is the list re-signing the mail and blaming
the list owner instead.

Mike

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Eric Kuhnke]

Anecdotal experience. I'm subscribed to a lot of mailing lists. Some pass
through DKIM correctly. Others re-sign the message with DKIM from their own
server.

>98% of the spam that gets through my filters, which comes from an IP not
in any of the major RBLs, has no DKIM signature for the domain. My theory
is that it does introduce somewhat of a barrier to spam senders because
they are frequently not in control of the mail server (which may be some
ignorant third party's open relay), nor do they have access to the zonefile
for the domain the mail server belongs to for the purpose of adding any
sort of DKIM record.



On Wed, Nov 29, 2017 at 10:12 AM, Michael Thomas  wrote:

> On 11/29/2017 10:03 AM, valdis.kletni...@vt.edu wrote:
>
>> On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said:
>>
>> There are quite a few things you can do to get the mailing list
>>> traversal rate > 90%, iirc.
>>>
>> Only 90% should be considered horribly broken.  Anything that makes
>> it difficult to run a simple mailing list with less that at least 2 or 3
>> 9's
>> is unacceptable.
>>
>
> I've been saying for years that it should be possible to create the
> concept of DKIM-friendly mailing lists. In such
> a case, you could have your nines. Until then, the best you can hope for
> is the list re-signing the mail and blaming
> the list owner instead.
>
> Mike
>
>

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Michael Thomas]

On 11/29/2017 10:03 AM, valdis.kletni...@vt.edu wrote:

On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said:


There are quite a few things you can do to get the mailing list
traversal rate > 90%, iirc.

Only 90% should be considered horribly broken.  Anything that makes
it difficult to run a simple mailing list with less that at least 2 or 3 9's
is unacceptable.


I've been saying for years that it should be possible to create the 
concept of DKIM-friendly mailing lists. In such
a case, you could have your nines. Until then, the best you can hope for 
is the list re-signing the mail and blaming

the list owner instead.

Mike

Re: Incoming SMTP in the year 2017 and absence of DKIM

[valdis . kletnieks]

On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said:

> There are quite a few things you can do to get the mailing list
> traversal rate > 90%, iirc.

Only 90% should be considered horribly broken.  Anything that makes
it difficult to run a simple mailing list with less that at least 2 or 3 9's
is unacceptable.


pgpIvpNci6U2A.pgp
Description: PGP signature

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Ken O'Driscoll]

On Wed, 2017-11-29 at 12:24 -0500, William Herrin wrote:
> Alright, so "horribly broken design" overstates the case but there are
> enough problems that weighting the absence of DKIM at something other
> than zero will surely do more harm than good.

+1. A DKIM signature by itself means nothing more than someone had the
ability to configure DKIM on an email server.

The signing domain (d=) is what matters as the signer needs access to the
zone in order to be able to publish the key, which may be interpreted as an
indication of trust.

DMARC requires the signing domain to be either exactly the same or share
the same organisational unit with the From address for this reason.

Even without DMARC, a receiver *could*, depending on the signing domain,
choose to interpret it as a positive signal. This is marginally better than
treating any DKIM signature or the absence thereof as a signal of any kind.

Personally, unless an author domain is publishing a DMARC policy of reject
or quarantine, I don't think recipients should be scoring based on DKIM at
all, perhaps with the exception of signing with a revoked key.

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Michael Thomas]

On 11/29/2017 09:24 AM, William Herrin wrote:

On Wed, Nov 29, 2017 at 12:17 PM, Stephen Frost  wrote:


* William Herrin (b...@herrin.us) wrote:

On Wed, Nov 29, 2017 at 12:03 PM, Eric Kuhnke 

wrote:

How much weight do you put on an incoming message, in terms of adding
additional score towards a possible value of spam, for total absence of
DKIM signature?

Zero. DKIM for mailing lists is a horribly broken design and legitimate
mailing lists are second only to spam in quantity of SMTP transactions.

Eh, that's really not accurate, imv, and some folks who run mailing
lists have put in serious effort to make sure to *not* break DKIM
signatures (which is certainly possible to do).


Alright, so "horribly broken design" overstates the case but there are
enough problems that weighting the absence of DKIM at something other than
zero will surely do more harm than good.



There are quite a few things you can do to get the mailing list 
traversal rate > 90%, iirc. For average mailman-like
lists like nanog it's very high. Of course while a "badly" behaving 
mailing list can trivially defeat any DKIM signature,
it doesn't really take too much effort to not behave "badly". Whether 
that false positive rate is too high is another

question.

Mike

Re: Incoming SMTP in the year 2017 and absence of DKIM

[William Herrin]

On Wed, Nov 29, 2017 at 12:17 PM, Stephen Frost  wrote:

> * William Herrin (b...@herrin.us) wrote:
> > On Wed, Nov 29, 2017 at 12:03 PM, Eric Kuhnke 
> wrote:
> > > How much weight do you put on an incoming message, in terms of adding
> > > additional score towards a possible value of spam, for total absence of
> > > DKIM signature?
> >
> > Zero. DKIM for mailing lists is a horribly broken design and legitimate
> > mailing lists are second only to spam in quantity of SMTP transactions.
>
> Eh, that's really not accurate, imv, and some folks who run mailing
> lists have put in serious effort to make sure to *not* break DKIM
> signatures (which is certainly possible to do).


Alright, so "horribly broken design" overstates the case but there are
enough problems that weighting the absence of DKIM at something other than
zero will surely do more harm than good.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Incoming SMTP in the year 2017 and absence of DKIM

[Stephen Frost]

Greetings,

* William Herrin (b...@herrin.us) wrote:
> On Wed, Nov 29, 2017 at 12:03 PM, Eric Kuhnke  wrote:
> 
> > For those who operate public facing SMTPd that receive a large volume of
> > incoming traffic, and accordingly, a lot of spam...
> >
> > How much weight do you put on an incoming message, in terms of adding
> > additional score towards a possible value of spam, for total absence of
> > DKIM signature?
> 
> Zero. DKIM for mailing lists is a horribly broken design and legitimate
> mailing lists are second only to spam in quantity of SMTP transactions.

Eh, that's really not accurate, imv, and some folks who run mailing
lists have put in serious effort to make sure to *not* break DKIM
signatures (which is certainly possible to do).  The combination of
making DKIM signatures work and DMARC allows messages to go through that
would otherwise end up getting bounced, from what I've seen.

What's annoying are the systems that appear to assume a DMARC policy
that says "bounce it if it's not from a server in our SPF list" when
there's no DMARC policy in place, but there is an SPF list.  Not
everyone really wants to put in the effort to set up DKIM, but they're
fine putting up an SPF record, but there seem to be a number of servers
out there that bounce mailing list traffic in those cases (seems to
specifically be MS Exchange systems, from the google'ing that I've
done).

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: Incoming SMTP in the year 2017 and absence of DKIM

[William Herrin]

On Wed, Nov 29, 2017 at 12:03 PM, Eric Kuhnke  wrote:

> For those who operate public facing SMTPd that receive a large volume of
> incoming traffic, and accordingly, a lot of spam...
>
> How much weight do you put on an incoming message, in terms of adding
> additional score towards a possible value of spam, for total absence of
> DKIM signature?
>

Zero. DKIM for mailing lists is a horribly broken design and legitimate
mailing lists are second only to spam in quantity of SMTP transactions.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: tracking TCP session hop by hop

[William Herrin]

On Tue, Nov 28, 2017 at 3:48 PM, Yifeng Zhou  wrote:

> Is there any way that we can track TCP session hop by hop?
>
> Say we have 10 ECMP between A and Z point, what's the easiest way to track
> specific session is using which path? How we can check between
> servers(Linux/Unix) and between Routers(Cisco/Juniper etc)?
>

A TCP connection is uniquely identified by the combination of four numbers:
The source IP address, the source port, the destination IP address and the
destination port. You used the word session, but sessions happen above TCP
in the stack and may use more than one TCP connection.  Every packet in the
connection contains all four numbers and no packet from any other
connection contains the same four numbers.

If you want to track the connections, you capture the packets at each point
in the path (router products have vendor-specific ways of doing this) and
see which unique sets of the four numbers went through which router and
router interface.


If you want to -test- which path a TCP connection -would- take, Ruairi's
afore-mentioned tcptraceroute is the way to go. The regular traceroute with
modern Linux servers also supports the "-T" flag which does the same thing.
It works just like regular traceroute but uses synthetic TCP SYN packets
instead of ICMP or UDP packets, allowing the packets to pass firewalls
which would otherwise block the trace.

Bear in mind that in each case you will likely only see the path taken at
the IP level. Underlying transits at the Ethernet or MPLS level are
intentionally invisible to the endpoints.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Incoming SMTP in the year 2017 and absence of DKIM

[Eric Kuhnke]

For those who operate public facing SMTPd that receive a large volume of
incoming traffic, and accordingly, a lot of spam...

How much weight do you put on an incoming message, in terms of adding
additional score towards a possible value of spam, for total absence of
DKIM signature?

Anyone from Earthlink here?

[Anne P. Mitchell Esq.]

If anybody is here from Earthlink - or knows anyone at Earthlink, could you 
pretty please connect with me?

Thank you!

Anne

Anne P. Mitchell, 
Attorney at Law
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant
CEO/President, Institute for Social Internet Public Policy
Legal Counsel: The CyberGreen Institute
Member, Cal. Bar Cyberspace Law Committee
Member, Colorado Cyber Committee
Member, Elevations Credit Union Member Council
Member, Board of Directors, Asilomar Microcomputer Workshop
Ret. Professor of Law, Lincoln Law School of San Jose
Ret. Chair, Asilomar Microcomputer Workshop

RE: tracking TCP session hop by hop

[Tyler Applebaum]

Somebody needs to renew their Let's Encrypt SSL cert.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jennifer Rexford
Sent: Wednesday, November 29, 2017 8:08 AM
To: Yifeng Zhou 
Cc: nanog@nanog.org
Subject: Re: tracking TCP session hop by hop

https://paris-traceroute.net/ 

> On Nov 28, 2017, at 3:48 PM, Yifeng Zhou  wrote:
>
> Hi Experts,
>
> Is there any way that we can track TCP session hop by hop?
>
> Say we have 10 ECMP between A and Z point, what's the easiest way to
> track specific session is using which path? How we can check between
> servers(Linux/Unix) and between Routers(Cisco/Juniper etc)?
>
> Thanks
>
> -Yifeng

Attention: Information contained in this message and or attachments is intended 
only for the recipient(s) named above and may contain confidential and or 
privileged material that is protected under State or Federal law. If you are 
not the intended recipient, any disclosure, copying, distribution or action 
taken on it is prohibited. If you believe you have received this email in 
error, please contact the sender with a copy to complia...@ochin.org, delete 
this email and destroy all copies.

Re: tracking TCP session hop by hop

[Jennifer Rexford]

https://paris-traceroute.net/ 

> On Nov 28, 2017, at 3:48 PM, Yifeng Zhou  wrote:
> 
> Hi Experts,
> 
> Is there any way that we can track TCP session hop by hop?
> 
> Say we have 10 ECMP between A and Z point, what's the easiest way to track
> specific session is using which path? How we can check between
> servers(Linux/Unix) and between Routers(Cisco/Juniper etc)?
> 
> Thanks
> 
> -Yifeng

Re: tracking TCP session hop by hop

[Ruairi Carroll]

Have a look at tcptraceroute:
https://github.com/mct/tcptraceroute/blob/master/examples.txt



On 28 November 2017 at 20:48, Yifeng Zhou  wrote:

> Hi Experts,
>
> Is there any way that we can track TCP session hop by hop?
>
> Say we have 10 ECMP between A and Z point, what's the easiest way to track
> specific session is using which path? How we can check between
> servers(Linux/Unix) and between Routers(Cisco/Juniper etc)?
>
> Thanks
>
> -Yifeng
>

RE: ATT AVPN BGP Communities

[Naslund, Steve]

Ask your AT rep to get you the AVPN routing guide.  That have a whole list of 
functions that can be manipulated by changing community information you send 
with a route.  It is very useful and you would never figure it all out by just 
messing with it.  I would send it to you but I don't have access at the moment.

Steven Naslund
Chicago IL

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ryan, Spencer
Sent: Wednesday, November 29, 2017 8:54 AM
To: nanog@nanog.org
Subject: ATT AVPN BGP Communities

Hey All,

Does anyone know if AVPN lets end users set/add their own communities to 
routes? I see that they stamp several on the routes we originate (Community: 
13979:2741 13979:2943 13979:5000 13979:6551) and curious if anyone had luck 
adding their own before I go start mucking around.

Thanks!



Spencer Ryan | Senior Systems Administrator | 
sr...@arbor.net
Arbor Networks | The security division of NETSCOUT
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

Packet Loss through Level 3 in Southern California?

[Gregorio Focaccio]

Hi All,

We are an MSP in San Diego that also offers multi-datacenter Colo and Cloud 
hosting.  We are multi-homed with Level 3 and Cogent.

A physical server client reported newly slow FTP transfers, so we started a 
network investigation.

Our data (see below) seem to show packet loss through Level 3 with associated 
slow TCP based data transfers.

Is anyone else seeing packet loss and consequent slow TCP based transfers when 
going through Level 3 in (LosAngeles1) Southern California?

Thanks,
Greg Focaccio
CARI.net


Testing Data:

** Internal tests - OK **
FTP transfers from client server to another server 3 hops away in our adjacent 
datacenter was normal


** Level 3 data - packet loss **
External tests via Level 3  - 12% Packet Loss - see data below
  UDP IPERF testing from our data center (through Level 3 and Microsoft - trace 
below) to an Azure server showed repeatable packet loss
   TCP based testing - such as FTP or SCP transfers - the rate was very slow 
about 4Mbps

[root@raynor ~]# iperf3 -c 40.80.156.2 -b 1m
Connecting to host 40.80.156.2, port 5201
[  4] local 71.6.220.101 port 55684 connected to 40.80.156.2 port 5201
[ ID] Interval   Transfer Bandwidth   Retr  Cwnd
[  4]   0.00-1.00   sec  1001 KBytes  8.20 Mbits/sec   34   9.76 KBytes
[  4]   1.00-2.00   sec   503 KBytes  4.12 Mbits/sec   12   11.2 KBytes
[  4]   2.00-3.00   sec   502 KBytes  4.11 Mbits/sec3   25.1 KBytes
[  4]   3.00-4.00   sec   502 KBytes  4.11 Mbits/sec   12   11.2 KBytes
[  4]   4.00-5.00   sec   377 KBytes  3.08 Mbits/sec9   15.3 KBytes
[  4]   5.00-6.00   sec   502 KBytes  4.11 Mbits/sec   10   19.5 KBytes
[  4]   6.00-7.00   sec   377 KBytes  3.09 Mbits/sec   13   6.97 KBytes
[  4]   7.00-8.00   sec   251 KBytes  2.06 Mbits/sec9   5.58 KBytes
[  4]   8.00-9.00   sec   251 KBytes  2.06 Mbits/sec6   9.76 KBytes
[  4]   9.00-10.00  sec   251 KBytes  2.06 Mbits/sec   10   12.6 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-10.00  sec  4.41 MBytes  3.70 Mbits/sec  118 sender
[  4]   0.00-10.00  sec  4.24 MBytes  3.56 Mbits/sec  receiver
iperf Done.

[root@raynor ~]# iperf3 -u -c 40.80.156.2 -b 1m
Connecting to host 40.80.156.2, port 5201
[  4] local 71.6.220.101 port 39221 connected to 40.80.156.2 port 5201
[ ID] Interval   Transfer Bandwidth   Total Datagrams
[  4]   0.00-1.00   sec  85.0 MBytes   712 Mbits/sec  62402
[  4]   1.00-2.00   sec  94.0 MBytes   789 Mbits/sec  69043
[  4]   2.00-3.00   sec  92.6 MBytes   777 Mbits/sec  68030
[  4]   3.00-4.00   sec  76.5 MBytes   641 Mbits/sec  56153
[  4]   4.00-5.00   sec  94.9 MBytes   796 Mbits/sec  69662
[  4]   5.00-6.00   sec  97.7 MBytes   819 Mbits/sec  71713
[  4]   6.00-7.00   sec  98.5 MBytes   826 Mbits/sec  72347
[  4]   7.00-8.00   sec  92.7 MBytes   778 Mbits/sec  68085
[  4]   8.00-9.00   sec  91.3 MBytes   765 Mbits/sec  67045
[  4]   9.00-10.00  sec  59.3 MBytes   498 Mbits/sec  43551
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   JitterLost/Total 
Datagrams
[  4]   0.00-10.00  sec   883 MBytes   740 Mbits/sec  0.014 ms  75647/647955 
(12%)
[  4] Sent 647955 datagrams
iperf Done.

[root@raynor ~]# traceroute 40.80.156.2
traceroute to 40.80.156.2 (40.80.156.2), 30 hops max, 60 byte packets
1  gateway (71.6.220.97)  6.170 ms  7.827 ms  10.718 ms
2  209.126.134.65 (209.126.134.65)  0.426 ms  0.420 ms  0.543 ms
3  216.98.153.21 (216.98.153.21)  159.936 ms  160.215 ms  160.209 ms
4  gi1-2.gw65-50.c5.sdcix.net (216.98.153.89)  170.977 ms  170.972 ms  170.964 
ms
5  xe-8-3-3.bar1.SanDiego1.Level3.net (4.16.105.93)  0.547 ms  0.586 ms  0.533 
ms
6  * * *
7  * * *
8  Microsoft-level3-20G.LosAngeles1.Level3.net (4.68.111.122)  17.296 ms  
18.026 ms  20.200 ms
9  be-61-0.ibr01.lax03.ntwk.msn.net (104.44.8.104)  30.108 ms  32.300 ms  
32.283 ms
10  be-4-0.ibr01.by2.ntwk.msn.net (104.44.4.3)  30.364 ms  30.961 ms  28.960 ms
11  104.44.7.198 (104.44.7.198)  31.870 ms  30.120 ms  29.636 ms
12  ae100-0.icr01.by21.ntwk.msn.net (104.44.11.194)  27.828 ms 
ae101-0.icr01.by4.ntwk.msn.net (104.44.11.193)  29.611 ms 
ae100-0.icr01.by21.ntwk.msn.net (104.44.11.194)  27.710 ms
13  * * *

[root@raynor ~]# scp ubuntu-14.04.5-desktop-amd64.iso 
carinet@40.80.156.2:/home/carinet/ubuntunew11.iso
ubuntu-14.04.5-desktop-amd64.iso 100% 1053MB 730.8KB/s   
24:35

LEVEL3 - summary
CARIcloud to Azure
2 Mbits/s TCP iperf
800 Mbits/s UDP iperf
24m and 35s 1053 MB upload to Azure through SCP


** Cogent data - OK **
External tests via Cogent - OK - No significant loss - see IPERF and trace data 
below

[root@raynor ~]# iperf3 -c 40.80.156.2 -b 1m
Connecting to host 40.80.156.2, port 5201
[  4] local 71.6.220.101 port 

Re: Any one from Akamai here ? Got a problem.

[Barrantes, Jorge via NANOG]

Hi Bob,

I’ll forward this to our network team to check the regions on those locations.

Jorge Barrantes Senior Solutions Engineer – Enterprise & Carrier
 
Akamai Technologies, Costa Rica 
 
Connect with Us:
     
    
  

 

On 11/28/17, 7:02 PM, "Bob Evans"  wrote:

We do not know why we are being blockedat www.costco.com
Name:   e6025.a.akamaiedge.net
Address: 104.96.118.20

Appears only via Los Angeles. Other paths , via San Jose , Palo Alto - via
other transits all work fineto this IP address.

Here is the error reported to several sites all on Akamai.

Access Denied

You don't have permission to access "http://www.costco.com/; on this server.
Reference #18.c60ad717.1511897450.524468b7

Access Denied

You don't have permission to access "http://www.costco.com/services.html;
on this server.
Reference #18.c60ad717.1511898193.52508dce


Access Denied

You don't have permission to access "http://www.loopnet.com/index.html; on
this server.
Reference #18.940ad717.1511898022.2f14cff8


Thank You
Bob Evans
CTO

ATT AVPN BGP Communities

[Ryan, Spencer]

Hey All,

Does anyone know if AVPN lets end users set/add their own communities to 
routes? I see that they stamp several on the routes we originate (Community: 
13979:2741 13979:2943 13979:5000 13979:6551) and curious if anyone had luck 
adding their own before I go start mucking around.

Thanks!



Spencer Ryan | Senior Systems Administrator | 
sr...@arbor.net
Arbor Networks | The security division of NETSCOUT
+1.734.794.5033 (d) | +1.734.846.2053 (m)
www.arbornetworks.com

tracking TCP session hop by hop

[Yifeng Zhou]

Hi Experts,

Is there any way that we can track TCP session hop by hop?

Say we have 10 ECMP between A and Z point, what's the easiest way to track
specific session is using which path? How we can check between
servers(Linux/Unix) and between Routers(Cisco/Juniper etc)?

Thanks

-Yifeng