Re: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T

[Michael StJohns]

At 10:02 AM 3/28/2013, John C Klensin wrote:
>   For me, it seems especially odd when
>compared to the liaison position to the ICANN Board.  Both are
>very important to the IETF community.  Both involve
>organizations with which the IETF has a complicated and
>multidimensional relationship.  Both involve issues that are
>very sensitive.   Yet the IAB conducted an open call for
>volunteers, followed by an open call for community comments, for
>one position and simply announced the appointment for the other.
>I think an explanation of the difference would be helpful for
>everyone.


The ICANN position of IETF Liaison is defined in the ICANN charter and has a 
specific fixed term, as such it gets handled via a call for volunteers and an 
appointment by the IAB.   AFAIK - there is no "IETF appoints a liaison to the 
ITU-T board" position defined. I believe the actual "liaison" status is between 
the IETF/ISOC and the ITU-T and the IETF ITU-T liaison acts more as a point of 
contact than anything else.  I find it telling that RFC6756 doesn't even 
mention a role for a specified person designated as liaison.

I would assume this accounts for the difference.  (Formal role vs informal/ad 
hoc role).

Mike

Re: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T

[Michael StJohns]

At 01:14 AM 3/29/2013, David Kessens wrote:

>Mike,
>
>On Thu, Mar 28, 2013 at 09:03:25PM -0400, Michael StJohns wrote:
>>
>> The process for selecting and appointing liaisons is the purview of the
>> IAB and not currently subject to external review - and I don't find any
>> problem with that.
>
>I fully agree with this.


But then you go on to say:  


>All I am asking for is a call for volunteers.


If it's within their purview, they get to decide what process they'll follow.  
If they need volunteers, I expect them to ask us.  If they already have someone 
to do the job and they're happy with them, I expect them to get on with it.  I 
don't think this needs to be a rule.  And I think it's mostly unnecessary.


>I am not even asking for publication of the resulting list of volunteers to
>allow for public comments.

And that would be a second bridge too far.


>The IAB, the IESG or whatever body in the IETF that needs to fill a position
>cannot possibly know all possible candidates for a position. The IETF is not
>a small community any longer where everybody knows each other. It is very
>easy to overlook good potential candidates. An open call helps the bodies
>that make the decisions to find as many candidates as possible. How can
>potential candidates even know that somebody is looking for a candidate if
>the potential candidate is not part of the incrowd him/herself ?

Liaison's generally have very little authority.  They act primarily as a point 
of presence.  And for things like the ITU-T, you really need to get someone who 
has a firm anchor in the other organization.  Back in pre-history (my first 
term on the IAB), most of the liaison requests come in from other organizations 
(e.g. will you accept X as a liaison) rather than the IETF seeking to appoint 
someone to represent us.  There are lot of nuances and there will be 
organizations where we want to ask for volunteers, organizations where the IAB 
is looking for one specific set of skills and finds it, and organizations where 
we'll say "yeah, sure, X can be a liaison".  


>And yes, I speak from experience: I have been an Area Director and I did
>open calls for volunteers whenever a position needed to filled.

You had open calls for volunteers for working group chairs?

> It involves
>some extra work but I did find that there were many more capable people that
>could fullfill the roles than I would have thought before I initiated such a
>call (the pool of candidates often turned out to much heathier than my
>initial guess of a "thin" pool).


Fair - but these are apples and oranges.  What worked well for you in your 
area, might work well for one organization, be a total political disaster for 
another and scare off the guy who just wanted to pass on something from a third.

Can't we just trust the IAB to do its job?  If we can't, then we either need to 
change the scope of the job, or select a whole new IAB.

Mike



>David Kessens
>---

Re: Appointment of Scott Mansfield as new IETF Liaison Manager to the ITU-T

[Brian E Carpenter]

On 29/03/2013 07:33, Michael StJohns wrote:
> At 01:14 AM 3/29/2013, David Kessens wrote:
> 
>> Mike,
>>
>> On Thu, Mar 28, 2013 at 09:03:25PM -0400, Michael StJohns wrote:
>>> The process for selecting and appointing liaisons is the purview of the
>>> IAB and not currently subject to external review - and I don't find any
>>> problem with that.
>> I fully agree with this.
> 
> 
> But then you go on to say:  
> 
> 
>> All I am asking for is a call for volunteers.
> 
> 
> If it's within their purview, they get to decide what process they'll follow. 
>  

Of course, and I didn't hear anybody suggesting that we need to update some
BCP or other for this. But for a whole lot of reasons, including the case
of a collective blind spot in the IAB, calling for volunteers is a
suggestion that IMHO the IAB would do well to adopt in future.

Anyone who reads RFC 4052, 4053 and 4691 will realise that they are not
volunteering for a trivial job.

Brian

Re: Sufficient email authentication requirements for IPv6

[Mikael Abrahamsson]

On Thu, 28 Mar 2013, Douglas Otis wrote:

IPv6 makes publishing IP address reputations impractical.  Since IP 
address reputation has been a primary method for identifying abusive 
sources with IPv4, imposing ineffective and flaky replacement strategies 
has an effect of deterring IPv6 use.


My belief is that IP address reputation has always been flakey, it's just 
vastly more so with IPv6.


What we need is a way to identify a "entity" subnet size. This work is 
probably wasted on IPv4, but it's definitely needed for IPv6. The ISP in 
question needs to be able to publish customer/entity subnet size so 
reputation can be done at this level.


This information might today be available using whois to the RIR, but 
that's not very practical publication method for quick lookups.

Re: Sufficient email authentication requirements for IPv6

[John Curran]

On Mar 29, 2013, at 4:13 AM, Mikael Abrahamsson  wrote:

> My belief is that IP address reputation has always been flakey, it's just 
> vastly more so with IPv6.
> 
> What we need is a way to identify a "entity" subnet size. This work is 
> probably wasted on IPv4, but it's definitely needed for IPv6. The ISP in 
> question needs to be able to publish customer/entity subnet size so 
> reputation can be done at this level.

This approach works fine if one presumes that the problem is always just
the customer (i.e. their ISP is actively interested in helping solve the 
problem.)  For ISPs who are not as interested (or may have an actual 
motivation to hinder resolution of the problem), this will not work.  

While the above situation has also been somewhat true with IPv4, it is 
definitely the case with IPv6, since the typical address space allocation 
sizes provide ample space for whitewashing customers into new prefixes.  
As a result, it is questionable whether any IPv6 address-based reputation 
system can be successful (at least those based on voluntary principles.)

/John

Re: Sufficient email authentication requirements for IPv6

[Mikael Abrahamsson]

On Fri, 29 Mar 2013, John Curran wrote:

This approach works fine if one presumes that the problem is always just 
the customer (i.e. their ISP is actively interested in helping solve the 
problem.)  For ISPs who are not as interested (or may have an actual 
motivation to hinder resolution of the problem), this will not work.


Well, I would also like to see reputation done on per-ISP level. If an ISP 
doesn't care, then the reputation of all the customers behind that ISP is 
lower.


While the above situation has also been somewhat true with IPv4, it is 
definitely the case with IPv6, since the typical address space 
allocation sizes provide ample space for whitewashing customers into new 
prefixes. As a result, it is questionable whether any IPv6 address-based 
reputation system can be successful (at least those based on voluntary 
principles.)


This is absolutely a problem. I encourage all ISPs to give customers the 
same addresses all the time, and publish if they provide dynamic. This is 
one more factor which should be included in the publication 
(static/dynamic allocation of addresses). So basically dynamic ones should 
be treated like "dialup space" today, static ones can actually be trusted 
if the ISP is reliable. If static and reliable ISP = reputation of one 
customer of allocation size can be blacklisted without affecting other 
customers.


ISPs that do this reliably should have high reputation, and the ones who 
don't, should get low reputation. Low reputation ISPs I guess none of 
this data should be trusted.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Last Call: (Security Implications of IPv6 on IPv4 Networks) to Informational RFC

[Brian E Carpenter]

Hi,

My minimal request for this draft is for my name to be removed from
the Acknowledgements, as I do not think that my comments have been
acted on.

In fact, I think that in its current state, this document is harmful
to IPv6 deployment. It in effect encourage sites to fence themselves
into an IPv4-only world. Particularly, it explicitly suggests a
default/deny approach to IPv6-in-IPv4 tunnels, which would prevent
the typical "baby steps" first approach to IPv6 deployment.

I would like to see the document convey a positive message, suggesting
that an IPv4 site first decides which IPv6 deployment mechanism it
will use, and then configures security appropriately (to allow that
mechanism and block all others). This wouldn't affect the technical
recommendations much if at all.

A specific aspect of this is that if a site provides one well-managed
6in4 tunnel mechanism, all tunneled IPv6 packets will pass through
well-defined points where security mechanisms may be applied.

We shouldn't imply that not having an IPv6 plan and blocking all IPv6
by default is a sound strategy.

Regards
   Brian

Gen-ART review of draft-ietf-pkix-rfc2560bis-16

[Black, David]

The -16 version of this draft resolves all of the concerns raised by the
Gen-ART review of the -15 version.

Thanks,
--David

> -Original Message-
> From: Black, David
> Sent: Monday, March 25, 2013 8:26 PM
> To: s...@aaa-sec.com; mmy...@fastq.com; ambar...@gmail.com;
> slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; gen-...@ietf.org
> Cc: Black, David; p...@ietf.org; Sean Turner; ietf@ietf.org
> Subject: Gen-ART review of draft-ietf-pkix-rfc2560bis-15
> 
> Authors,
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
> please
> see the FAQ at .
> 
> Please resolve these comments along with any other Last Call comments you may
> receive.
> 
> Document: draft-ietf-pkix-rfc2560bis-15
> Reviewer: David L. Black
> Review Date: March 25, 2013
> IETF LC End Date: March 27, 2013
> 
> Summary:
> This draft is on the right track but has open issues, described in the review.
> 
> This draft updates the OCSP protocol for obtaining certificate status
> with some minor extensions.
> 
> Because this is a "bis" draft, I reviewed the diffs against RFC 2560.
> 
> I did not check the ASN.1.  I also did not see a writeup for this draft
> in the data tracker, and so will rely on the document shepherd to
> ensure that the ASN.1 has been checked when the writeup is prepared.
> 
> I found five open issues, all of which are minor, plus one idnits item
> that is probably ok, but should be double-checked.
> 
> Minor issues:
> 
> [1] Section 2.2:
> 
>   NOTE: The "revoked" state for known non-issued certificate serial
>   numbers is allowed in order to reduce the risk of relying
>   parties using CRLs as a fall back mechanism, which would be
>   considerably higher if an "unknown" response was returned.
> 
> Given this explanation, I'm surprised that the use of "revoked" instead of
> "unknown" for a known non-issued certificate is a "MAY" requirement and
> not a "SHOULD" requirement.  Why is that the case?
> 
> It appears that the reason is that the use of "revoked" in this situation
> may be dangerous when serial numbers can be predicted for certificates that
> will be issued in the future.  If that's what's going on, this concern is
> already explained in the security considerations section, but it should
> also be mentioned here for completeness.
> 
> [2] Section 4.2.2.2:
> 
>   The key that signs a certificate's status information need not be the
>   same key that signed the certificate. It is necessary however to
>   ensure that the entity signing this information is authorized to do
>   so.  Therefore, a certificate's issuer MAY either sign the OCSP
>   responses itself or it MAY explicitly designate this authority to
>   another entity.
> 
> The two instances of "MAY" in the above text were both "MUST" in RFC 2560.
> 
> The RFC 2560 text construction of "MUST" or "MUST" is a bit odd, but the two
> "MAY"s in this draft are even worse, as they allow "MAY do something else
> entirely", despite being enclosed in an either-or construct.  I strongly
> suspect that the latter was not intended, so the following would be clearer:
> 
>   The key that signs a certificate's status information need not be the
>   same key that signed the certificate. It is necessary however to
>   ensure that the entity signing this information is authorized to do
>   so.  Therefore, a certificate's issuer MUST do one of the following:
>   - sign the OCSP responses itself, or
>   - explicitly designate this authority to another entity.
> 
> [3] Section 4.3:
> 
> Is the "SHOULD" requirement still appropriate for the DSA with SHA-1 combo
> (vs. a "MAY" requirement)?  This requirement was a "MUST" in RFC 2560, but
> I wonder about actual usage of DSA in practice.
> 
> [4] Section 5, last paragraph:
> 
>   Responding a "revoked" state to certificate that has never been
>   issued may enable someone to obtain a revocation response for a
>   certificate that is not yet issued, but soon will be issued, if the
>   CA issues certificates using sequential certificate serial number
>   assignment.
> 
> The above text after starting with the "if" is too narrow - it should say:
> 
>   if the certificate serial number of the certificate that
>   will be issued can be predicted or guessed by the requester.
>   Such prediction is easy for a CA that issues certificates
>   using sequential certificate serial number assignment.
> 
> There's also a nit in original text - its first line should be:
> 
>   Responding with a "revoked" state for a certificate that has never been
> 
> [5] Section 5.1.1:
> 
>   In archival applications it is quite possible that an OCSP responder
>   might be asked to report the validity of a certificate on a date in
>   the distant past. Such a certificate might employ a signing method
>   that 

Re: Sufficient email authentication requirements for IPv6

[John Levine]

>As a result, it is questionable whether any IPv6 address-based reputation 
>system can be successful (at least those based on voluntary principles.)

It can probably work for whitelisting well behaved senders, give or take
the DNS cache busting issues of IPv6 per-message lookups.

Since a bad guy can easily hop to a new IP for every message (offering
interesting new frontiers in listwashing) I agree that it's a losing
battle for blacklisting, other than blocking large ranges of hostile
networks.

Fortunately, the IETF as a whole is not called upon to solve this
problem right now.  People interested in mail reputation are welcome
to drop by the spfbis WG and the discussions in appsarea about
updating authentication and authentication logging RFCs.

Re: Sufficient email authentication requirements for IPv6

[Douglas Otis]

On Mar 29, 2013, at 9:58 AM, "John Levine"  wrote:

>> As a result, it is questionable whether any IPv6 address-based reputation 
>> system can be successful (at least those based on voluntary principles.)
> 
> It can probably work for whitelisting well behaved senders, give or take
> the DNS cache busting issues of IPv6 per-message lookups.
> 
> Since a bad guy can easily hop to a new IP for every message (offering
> interesting new frontiers in listwashing) I agree that it's a losing
> battle for blacklisting, other than blocking large ranges of hostile
> networks.
> 
> Fortunately, the IETF as a whole is not called upon to solve this
> problem right now.  People interested in mail reputation are welcome
> to drop by the spfbis WG and the discussions in appsarea about
> updating authentication and authentication logging RFCs.

Dear John,

The Internet is under a DDoS attack specifically against an email address 
reputation service.  This affects everyone, especially the IETF.

Strategies not premised on low overhead AUTHENTICATION are of little benefit.   
We can no longer continue business as usual.  I call upon the IETF to solve 
this problem.  It is within their charter.  It is within their capabilities.  
We can not make everyone upgrade, but we can establish a path that has a chance 
of offering a solution.

Regards,
Douglas Otis

Call for volunteers for IETF ITU-T Liaison Manager for MPLS

[Scott Mansfield]

The IAB will be appointing a liaison manager to ITU-T for MPLS within the next 
few weeks. We are soliciting volunteers for this position. Nominations 
(including self-nominations) for this position should be sent to: 
scott.mansfi...@ericsson.com  no later 
than Sunday April 14, 2013.



The person filling the role of MPLS Liaison to the ITU-T needs to have 
familiarity with the IETF process and the MPLS, CCAMP, and PWE3 groups.  The 
MPLS Liaison manager also needs to understand the ITU-T process and procedures 
(including the traditional approval process, the alternative approval process, 
and the ITU-T governance structure). An understanding of the study groups in 
the ITU-T that are working in areas that use or affect MPLS technologies is 
beneficial. The IETF liaison process is defined in RFCs 4052, 4053, and 4691.



Regards,

Scott Mansfield

IETF - ITU-T Liaison Manager

Scott Mansfield
Ericsson Inc.
300 Holger Way
San Jose, CA 95134

Re: Sufficient email authentication requirements for IPv6

[Doug Barton]

On 03/28/2013 08:29 PM, Douglas Otis wrote:

IPv6 makes publishing IP address reputations impractical.


For individual addresses, sure. But one of the (if not *the*) primary 
benefits of v4 reputation is the test of whether or not the address is 
in a botnet range (aka, ranges assigned to end-users). That will still 
work quite nicely with IPv6, assuming that the ISPs cooperate at roughly 
the same levels they do now with IPv4.



Since IP
address reputation has been a primary method for identifying abusive
sources with IPv4, imposing ineffective and flaky replacement strategies
has an effect of deterring IPv6 use.


I personally don't believe this is true. One of the things that IPv6 
advocates encourage folks to do is to put their mail infrastructure on 
IPv6 first as a test, since the mail protocol is relatively forgiving. 
That is a good piece of advice, which a lot of sites seem to have followed.


That said, I don't necessarily disagree with your thoughts about domain 
reputation vs. IP address reputation. I think that there is room for 
discussion about that.


On the other hand I don't agree with your negative view about DKIM and 
SPF. I recently moved from an IHP to my own VPS, and set up both DKIM 
and SPF for my active domains. The former has allowed me to send mail to 
various places that didn't accept mail from my old IHP's servers. And I 
have a hard-fail on my SPF records, and that has cut to nearly zero the 
amount of Joe-job backscatter I receive (whereas previously it was in 
the 3-10 messages per day range).


I don't think either mechanism is perfect, and I'm intrigued by DMARC 
although I haven't really had time to study it yet. But in my anecdotal 
experience both DKIM and SPF are useful at least, and seem to work well, 
so I'd hate to see them out with the bathwater.


Doug

Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06

[Joel M. Halpern]

I have a draft version with this correction.
David, would adding:
  When such a move
  is done without changing the MAC address, the SAVI switches
  will need to update their state.  While the ARP may be
  helpful,
  traffic detection, switch based neighbor solicitation,
  interaction with orchestration system, or other means may be
  used.
to the end of 5.2.3 address your concern?  I am not sure whether I have 
the right end of the question here, given that SAVI can not create new 
protocol.


Yours,
Joel

On 3/27/2013 10:56 PM, Ted Lemon wrote:

On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct  
wrote:


Then it will be done.  I will wait for the AD to decide what other changes are 
needed, and then will either make this change or include it in an RFC Editor 
note.



Old:
   If the bridging topologies which connects the switches changes, or
   if LACP [IEEE802.3ad] changes which links are used to deliver
   traffic, the switch may need to move the SAVI state to a different
   port, are the state may need to be moved or reestablished on a
   different switch.
New:
   If the bridging topologies which connects the switches changes, or
   if LACP [IEEE802.3ad], VRRP, or other link management
   operations, change which links are used to deliver
   traffic, the switch may need to move the SAVI state to a different
   port, are the state may need to be moved or reestablished on a
   different switch.


I think you probably meant "or", not "are", in the second word of the 
second-to-last line of the new text.

As far as I am concerned, given that David is happy with your recent change, 
I'm happy with it too.   However, since you are asking, if you were willing to 
also accommodate David's other request (see below) by adding some text to the 
document in section 5, that would be an added bonus:


A paragraph has been added to 5.2.3 to address all three of the above concerns. 
  I guess that's ok, but I would have liked to see some text pointing out that 
a MAC move can be detected by the switches and used to update SAVI state about 
which port(s) a MAC is accessed through.


So if you can do this, it would be much appreciated; if you can't do it, I 
think the document is valuable enough to move forward without this additional 
work.