Re: Sufficient email authentication requirements for IPv6

[Douglas Otis]

On Mar 30, 2013, at 11:26 PM, Christian Huitema  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. 
> 
> In practice, the /64 prefix of the IPv6 address has very much the same 
> "administrative" properties as the /32 value of the IPv4 address. It should 
> be fairly straightforward to update a reputation system to manage the /64 
> prefixes of IPv6. This seems somewhat more practical than trying to change 
> the behavior of mail agent if their connectivity happens to use IPv6.

Dear Christian,

The announced prefix space currently represents more than 4 million times the 
entire IPv4 address space.  This means the /64 prefix space can not be 
considered comparable to IPv4 address space.  Go to 
http://bgp.potaroo.net/v6/as2.0/ and look for Total address space advertised 
(/64 equiv).  The number of announced prefixes over /64s currently shows 
18,206,079,529,779,202.

Much of the IPv4 has already had Reverse DNS PTR records traversed scanning for 
hints about whether any specific address appears to represent dynamically 
assigned access.  This guesswork allows about 1/3 of the IPv4 space to be 
ignored by blocking them from sending public (port 25) SMTP messages.

Reverse DNS PTR records offers a costly means to differentiate residential and 
non-residential access when done on a realtime basis.  A significant benefit of 
a comprehensive reputation mapping of the entire IPv4 address space is that any 
reverse naming exceptions are incorporated into the reputation values which 
also eliminates dependence on reverse DNS performance.

In IPv6, there can not be any pre-mapping.  This places reverse PTR review at 
the mercy of the even more broken IPv6 reverse zone provisioning.  Any 
mis-configuration of the reverse name space, which is common for IPv4 from 
residential systems, greatly increases the resources consumed by the growing 
proportion of sessions emitted by compromised systems.  Few expect reverse PTRs 
and hostnames to match, but to offer names not hinting at being for a dynamic 
assignment.  Greatly increased delays caused by DNS misconfiguration, along 
with a need to handle a larger number of sessions, will make testing reverse 
PTR records highly resource prohibitive and problematic for IPv6.

In the end, Reverse PTRs can be assigned any name and thus can not serve as a 
basis to assess accountability.  Once a conclusion is reached that only 
AUTHENTICATED initiating domains offer a means to fairly establish a basis for 
acceptance, use of reverse PTR records becomes far far less attractive.  The 
ability to authenticate forward domains initiating messages improves security 
and is better suited for a future of more mobile and dynamic infrastructure.

Many email domains will find themselves obligated to authorize IPv4 outbound 
servers using SPF.  Return-Path mail parameters locating authorization reduces 
backscatter abuse at the cost of reduced delivery integrity.  However this 
parameter's relationship over mail's entire path is too fragile to serve as a 
basis for acceptance.  Since DKIM allows any message to be relayed by design, 
it can not offer a means to mitigate abuse when any marginal domain must be 
accepted, as for domains considered too big to block.

In addition, problems related to DKIM header field spoofing permitted when 
signatures are still considered valid, along with a growing range of dangerous 
email content that references compromised i-frames, makes responding to new 
threats a growing problem.  IPv6 pushes this problem further over the edge 
without the introduction of the initiating domains having been authenticated.  
IPv6 addresses can not serve this function, and there is progress being made in 
respect to use of DANE and the like.

Regards,
Douglas Otis

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

[SM]

Hi Fernando,
At 16:30 02-04-2013, Fernando Gont wrote:

Happy eyeballs is about HTTP. But part of the approach predates "Happy
Eyeballs" -- please see RFC5461.


Ok.


Removing the  records when you're not going to allow such
connectivity reduces the potential problem (at the end of the day, this
is kind of the whitelisting approach that has been applied to the
general case by content providers -- with the caveat that in this case
you positively know that such connectivity is not present).


Here's an extract from RFC 4924:

  'In particular, the DNSSEC protocol described in "Protocol
   Modifications for the DNS Security Extensions" [RFC4035] has been
   designed to verify that DNS information has not been modified between
   the moment they have been published on an authoritative server and
   the moment the validation takes place.  Since that verification can
   take place at the application level, any modification by a recursive
   forwarder or other intermediary will cause validation failures,
   disabling the improved security that DNSSEC is intended to provide.'

I am ok with resolving the problem of the day.  If I am of the 
opinion that it may cause problems in the long run I'll mention 
it.  I am not inclined to do anything more than that.


Regards,
-sm 

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

[Ted Lemon]

On Apr 2, 2013, at 7:30 PM, Fernando Gont  wrote:
>> I agree with the last sentence.  Happy Eyeballs is about the HTTP. 
>> There are other applications protocols too. :-) 
> 
> Happy eyeballs is about HTTP. But part of the approach predates "Happy
> Eyeballs" -- please see RFC5461.

It's certainly true that we usually talk about Happy Eyeballs in the context of 
HTTP, but I use it for ssh as well, and I think it's applicable across a broad 
range of application protocols.   It is not applicable to _every_ protocol, but 
that's as strong a qualification as I'd put on it—saying it's only applicable 
to HTTP is not correct.

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

[Fernando Gont]

On 04/01/2013 06:14 PM, SM wrote:
>> with IPv6 connectivity. However, it's inappropriate to rely on
>> pervasive implementation of Happy Eyeballs as the sole solution to
>> prevent end host impacts, since the end user may not know that IPv6 is
>> actively being disabled on this network, or that their IPv6
>> implementation is otherwise broken. This is a problem that continues
>> to get worse the more dual-stack content becomes available.
> 
> I agree with the last sentence.  Happy Eyeballs is about the HTTP. 
> There are other applications protocols too. :-) 

Happy eyeballs is about HTTP. But part of the approach predates "Happy
Eyeballs" -- please see RFC5461.

Signaling hosts when packets are being dropped allows for a more
informed decision/reaction on the host-side.

Removing the  records when you're not going to allow such
connectivity reduces the potential problem (at the end of the day, this
is kind of the whitelisting approach that has been applied to the
general case by content providers -- with the caveat that in this case
you positively know that such connectivity is not present).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Stig Venaas]

On 4/2/2013 2:58 AM, Brian E Carpenter wrote:

Just picking a couple of points for further comment:

On 02/04/2013 08:46, Liubing (Leo) wrote:

Hi, Robert

...


-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]


...

The document currently references
draft-chown-v6ops-renumber-thinkabout
several times.
That document is long expired (2006). It would be better to simply
restate what is
important from that document here and reference it only once in the
acknowlegements
rather than send the reader off to read it.


[Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap 
analysis. Although the draft is expired, most of the content are still valid.
draft-chown is a more comprehensive analysis, while the gap draft is focusing 
on gaps in enterprise renumbering. So it might not easy to abstract several 
points as important from draft-chown to this draft. We actually encourage 
people to read it.


Robert is right, though, sending people to a long-expired draft is a bad idea.
Of course we have to acknowledge it, but maybe we should pull some of its text
into an Appendix.

Tim Chown, any opinion?


I still think that old draft is fairly good, and a shame to let it all
just die. But there is no chance of getting that out as an RFC I guess?

Stig




RFC4076 seems to say very similar things to this document. Should it
have been referenced?


[Bing] RFC4076 is a more specific case of stateless-DHCPv6 [RFC3736], which 
might not be common usage in enterprise. But sure we can consider reference it.


Yes, and check if it identifies any gaps that we should mention.

Bing: we should also add a reference to RFC 4085 "Embedding Globally-Routable
Internet Addresses Considered Harmful" which I missed for RFC 6866.


Section 5.3 punts discussion of static addresses off to RFC 6866. That
document was scoped
only to Enterprise Networks. The scope of this document is larger.


As Bing said, the *intended* scope is enterprise networks. We should
add that in the Abstract and Introduction. Indeed, many of the points
are more general.

Thanks again Robert!

Brian

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

[Bob Hinden]

AB,

On Apr 1, 2013, at 5:45 PM, Abdussalam Baryun  
wrote:

> RFC6921>It is well known that as we approach the speed of light, time
> slows down.
> AB> I know that time slows for something when it is in speed of light,
> but communication is not something moving. If the packet is in speed
> of light we may reduce the comm-delay but never less than zero. The
> communication times don't change if at least one communicator is not
> moving in light speed.
> 
> My comment is that I think this RFC is not logical, and I don't
> understand its recommendations. There is no way that a packet can be
> received before send, packet-time never changes communicators-time
> while the positions of both Tx and Rx are semi-fixed (change is
> relative to communicators' times not their signal). I think the
> communication-times may change when the communicators are at/above
> speed of light not the signal/packet. Is my physics correct?

Only time will tell.

Bob

Re: [mpls] Last Call:

[Luyuan Fang (lufang)]

Works for me. Thanks, Paul.
Luyuan

-Original Message-
From: , "Paul   (NSN - US/Irving)" 
Date: Tuesday, April 2, 2013 7:58 AM
To: Luyuan Fang , Russ Housley ,
"ietf@ietf.org" 
Cc: "m...@ietf.org" 
Subject: RE: [mpls] Last Call:


>Hi Luyuan,
>
>You wrote (in part):
>
>..since multiplexing of bursty sources is far more efficient over
>traditional circuit-based
>TDM technologies.
>
>Which is not true and probably not what you meant.
>
>A better formulation might be "since packet multiplexing of traffic from
>bursty sources provides more efficient use of bandwidth than traditional
>circuit-based TDM technologies".
>
>To be honest however, I'd cut the traditional and use only TDM (since
>some 'circuit' based technologies also offer packet multiplexing) so I'd
>reduce it to:
>
>A better formulation might be "since packet multiplexing of traffic from
>bursty sources provides more efficient use of bandwidth than TDM
>technologies".
>
>
>cheers,
>pd
>
>
>-Original Message-
>From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
>ext Luyuan Fang (lufang)
>Sent: Monday, April 01, 2013 9:05 PM
>To: Russ Housley; ietf@ietf.org
>Cc: m...@ietf.org
>Subject: Re: [mpls] Last Call:
>
>
>Hi Russ,
>
>Thanks for your comments, very good points.
>Sorry for the delay in replying, I was out of office.
>
> 
>The following is my proposed text for replacing the current first
>paragraph of section 1.2.
>
> 
>Traditional transport technologies include SONET/SDH, TDM, and ATM. There
>is a transition away from these transport technologies to new packet
>technologies.
>In addition to the ever increasing demand for bandwidth, the packet
>technologies offer these key advantages:
>
> 
>Bandwidth efficiency: Transport technologies supports fixed Bandwidth
>only, no packet statistical multiplexing, bandwidth is reserved in
>transport
>whether used or not by clients. Packet technologies support statistical
>multiplexing,
>this is the most important motivation for the transition from traditional
>transport technologies to packet technologies. The proliferation of new
>distributed applications which communicate with servers over the network
>in a
>bursty fashion has been driving the adoption of packet transport
>techniques, since
>multiplexing of bursty sources is far more efficient over traditional
>circuit-based
>TDM technologies.
>
> 
>Flexible data rate connections: Traditional transport connection
>granularity
>is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12,
>etc.).
>Packet technologies support flexible data rate connections. The support of
>finer data rate granularity is important for today¹s wireline and wireless
>services and applications.
>
> 
>QoS support: While traditional transport, such as TDM transport has
>very limited QoS support, packet transport can provide needed QoS
>treatment for
>IPTV, Voice and Video over IP applications.
>
> 
>The root cause for transport moving to packet transport is the shift
>of application from TDM to packet. For example, Voice TDM to VoIP; Video
>to
>Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and
>Ethernet
>VPNs. In addition, network convergence and technology refreshes demand for
>common and flexible infrastructure that provides multiple services.
>
> 
>Thanks,
>Luyuan
>
>
>
>-Original Message-
>From: Russ Housley 
>Date: Saturday, March 23, 2013 3:16 PM
>To: "ietf@ietf.org" 
>Cc: "m...@ietf.org" 
>Subject: Re: [mpls] Last
>Call:  
>
>>I wonder if the direction of Section 1.2 can be revised to make it more
>>of an engineering document.
>>
>>It currently says:
>>
>>   In recent years, the urgency for moving from traditional transport
>>   technologies, such as SONET/SDH, TDM, and ATM, to new packet
>>   technologies has been rising. This is largely due to the fast growing
>>   demand for bandwidth, which has been fueled by the following factors:
>>   ...
>>
>>Please consider an approach that describes the the reasons behind the
>>transition from the network operator and network user perspectives:
>>
>>   Traditional transport technologies include SONET/SDH, TDM, and ATM.
>>   There is a transition away from these transport technologies to new
>>   packet technologies. In addition to the ever increasing demand for
>>   bandwidth, the packet technologies offer these advantages:
>>   ...
>>
>>The fact that IP networks are being used for new applications and that
>>the legacy devices are getting old does not motivate the transition to
>>packet technologies.  The advantages that packet technologies offer for
>>these new applications is the thing that needs to be highlighted here,
>>even if it is just a list of bullets.
>>
>>It seems like the only sentence that addresses this point in Section 1.2
>>is: "It streamlines the operation, reduces the overall complexity, and
>>improves end-to-end convergence."
>>
>>Thanks,
>>  Russ
>>
>>On Jan 28, 2013, at 3:01 PM, The IESG wrote:
>>
>>> The IESG has received a reques

RE: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Liubing (Leo)]

Hi, Brian

> >> The document currently references
> >> draft-chown-v6ops-renumber-thinkabout
> >> several times.
> >> That document is long expired (2006). It would be better to simply
> >> restate what is
> >> important from that document here and reference it only once in the
> >> acknowlegements
> >> rather than send the reader off to read it.
> >
> > [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for
> the gap analysis. Although the draft is expired, most of the content are still
> valid.
> > draft-chown is a more comprehensive analysis, while the gap draft is
> focusing on gaps in enterprise renumbering. So it might not easy to abstract
> several points as important from draft-chown to this draft. We actually
> encourage people to read it.
> 
> Robert is right, though, sending people to a long-expired draft is a bad idea.
> Of course we have to acknowledge it, but maybe we should pull some of its
> text
> into an Appendix.
> 
> Tim Chown, any opinion?

[Bing] Ok, then we can hear some opinions from Tim.

> 
> >> RFC4076 seems to say very similar things to this document. Should it
> >> have been referenced?
> >
> > [Bing] RFC4076 is a more specific case of stateless-DHCPv6 [RFC3736],
> which might not be common usage in enterprise. But sure we can consider
> reference it.
> 
> Yes, and check if it identifies any gaps that we should mention.
> 
> Bing: we should also add a reference to RFC 4085 "Embedding
> Globally-Routable
> Internet Addresses Considered Harmful" which I missed for RFC 6866.

[Bing] Got it. I'll add it in the next version.

> >> Section 5.3 punts discussion of static addresses off to RFC 6866. That
> >> document was scoped
> >> only to Enterprise Networks. The scope of this document is larger.
> 
> As Bing said, the *intended* scope is enterprise networks. We should
> add that in the Abstract and Introduction. Indeed, many of the points
> are more general.

[Bing] OK. Thanks.

> Thanks again Robert!
> 
>Brian

RE: [mpls] Last Call:

[Doolan, Paul (NSN - US/Irving)]

Hi Luyuan,

You wrote (in part):

..since multiplexing of bursty sources is far more efficient over 
traditional circuit-based
TDM technologies.

Which is not true and probably not what you meant. 

A better formulation might be "since packet multiplexing of traffic from bursty 
sources provides more efficient use of bandwidth than traditional circuit-based 
TDM technologies".

To be honest however, I'd cut the traditional and use only TDM (since some 
'circuit' based technologies also offer packet multiplexing) so I'd reduce it 
to:

A better formulation might be "since packet multiplexing of traffic from bursty 
sources provides more efficient use of bandwidth than TDM technologies".


cheers,
pd


-Original Message-
From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of ext 
Luyuan Fang (lufang)
Sent: Monday, April 01, 2013 9:05 PM
To: Russ Housley; ietf@ietf.org
Cc: m...@ietf.org
Subject: Re: [mpls] Last Call: 

Hi Russ,

Thanks for your comments, very good points.
Sorry for the delay in replying, I was out of office.

 
The following is my proposed text for replacing the current first
paragraph of section 1.2.

 
Traditional transport technologies include SONET/SDH, TDM, and ATM. There
is a transition away from these transport technologies to new packet
technologies.
In addition to the ever increasing demand for bandwidth, the packet
technologies offer these key advantages:

 
Bandwidth efficiency: Transport technologies supports fixed Bandwidth
only, no packet statistical multiplexing, bandwidth is reserved in
transport
whether used or not by clients. Packet technologies support statistical
multiplexing,
this is the most important motivation for the transition from traditional
transport technologies to packet technologies. The proliferation of new
distributed applications which communicate with servers over the network
in a
bursty fashion has been driving the adoption of packet transport
techniques, since
multiplexing of bursty sources is far more efficient over traditional
circuit-based
TDM technologies.

 
Flexible data rate connections: Traditional transport connection
granularity
is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12,
etc.).
Packet technologies support flexible data rate connections. The support of
finer data rate granularity is important for today¹s wireline and wireless
services and applications.

 
QoS support: While traditional transport, such as TDM transport has
very limited QoS support, packet transport can provide needed QoS
treatment for
IPTV, Voice and Video over IP applications.

 
The root cause for transport moving to packet transport is the shift
of application from TDM to packet. For example, Voice TDM to VoIP; Video to
Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and
Ethernet
VPNs. In addition, network convergence and technology refreshes demand for
common and flexible infrastructure that provides multiple services.

 
Thanks,
Luyuan



-Original Message-
From: Russ Housley 
Date: Saturday, March 23, 2013 3:16 PM
To: "ietf@ietf.org" 
Cc: "m...@ietf.org" 
Subject: Re: [mpls] Last
Call:   

>I wonder if the direction of Section 1.2 can be revised to make it more
>of an engineering document.
>
>It currently says:
>
>   In recent years, the urgency for moving from traditional transport
>   technologies, such as SONET/SDH, TDM, and ATM, to new packet
>   technologies has been rising. This is largely due to the fast growing
>   demand for bandwidth, which has been fueled by the following factors:
>   ...
>
>Please consider an approach that describes the the reasons behind the
>transition from the network operator and network user perspectives:
>
>   Traditional transport technologies include SONET/SDH, TDM, and ATM.
>   There is a transition away from these transport technologies to new
>   packet technologies. In addition to the ever increasing demand for
>   bandwidth, the packet technologies offer these advantages:
>   ...
>
>The fact that IP networks are being used for new applications and that
>the legacy devices are getting old does not motivate the transition to
>packet technologies.  The advantages that packet technologies offer for
>these new applications is the thing that needs to be highlighted here,
>even if it is just a list of bullets.
>
>It seems like the only sentence that addresses this point in Section 1.2
>is: "It streamlines the operation, reduces the overall complexity, and
>improves end-to-end convergence."
>
>Thanks,
>  Russ
>
>On Jan 28, 2013, at 3:01 PM, The IESG wrote:
>
>> The IESG has received a request from the Multiprotocol Label Switching
>>WG
>> (mpls) to consider the following document:
>> - 'MPLS-TP Applicability; Use Cases and Design'
>>   as Informational RFC
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2013-02-11. Excepti

Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

[Eric Burger]

Works for me.

--
Sent from my mobile device. Thanks be to lemonade!  
http://www.standardstrack.com/ietf/lemonade/


-Original message-
From: Alexey Melnikov 
To: Burger Eric 
Cc: Robert Sparks , ietf@ietf.org
Sent: Tue, Apr 2, 2013 09:53:39 GMT+00:00
Subject: Re: Missing requirement in draft-sparks-genarea-imaparch?   
(was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)


Hi Eric,
I am sorry if I sound pedantic below, but I think your suggestion can be 
misinterpreted and thus needs improving:


On 28/03/2013 12:13, Burger Eric wrote:
Rather than guessing all of the bad things that could happen, I would  

offer it would be better to say what we mean, like:
	The IMAP interface MUST NOT provide any IMAP facilities that modify the  
underlying message and message metadata, such as mailbox, flags, marking for  
deletion, etc. If the client is authenticated and authorized, the IMAP  
interface MUST provide per-user marking of the underlying message as read or  
flagged.
One way to implement this is in an IMAP server is to always fail 
commands for modifying message metadata. Another way of implementing 
this is to allow them, but ignore (don't persist) results. Both ways 
were used in the past and they have different effect on IMAP clients. I 
hope the requirement is intended to allow for either.


Another thing to consider is that for IMAP servers that implement IMAP 
ACL, the easiest way to meet the intended requirement is by not allowing 
unauthorized users to access some commands on a mailbox. Again, a 
possible reading of your suggested text is that that is not allowed.


So, my suggestion is to change "MUST NOT provide any IMAP facilities 
..." to "MUST disallow any IMAP facilities ...".

RE: Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Liubing (Leo)]

Hi, Robert

Thanks a lot for your careful and detailed review. It is very helpful to refine 
the draft.
Please see replies inline. 

> -Original Message-
> From: Robert Sparks [mailto:rjspa...@nostrum.com]
> Sent: Tuesday, April 02, 2013 4:47 AM
> To: 6re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org
> Cc: gen-...@ietf.org; ietf@ietf.org
> Subject: Gen-art review: draft-ietf-6renum-gap-analysis-05.txt
> 
> 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-6renum-gap-analysis-05.txt
> Reviewer: Robert Sparks
> Review Date: April 1, 2013
> IETF LC End Date: April 10,2013
> IESG Telechat date: Not yet scheduled for a telechat
> 
> Summary: This document is not ready for publication as an Informational
> RFC.
>   It may be on the right track, but there issues both in substance
>   and form that need to be addressed.
> 
> Major issues:
> 
> The document doesn't provide what its title and abstract claim it will
> provide.
> For instance, the abstract claims a gap analysis is presented following
> a renumbering
> event procedure summary, but neither appear in the draft. 

[Bing] In fact the subtitles have the implication of a renumbering event 
procedure summary. But it is indeed not explicit in the main texts. We'll add 
some texts to represent it explicitly in the next version.

> There are a few places
> in the text that say "this is a gap", but usually it's not clear what
> "this" means.

[Bing] We'll make them more clear in the next version. 
 
> The stated intent is to identify missing capabilities (gaps) and the work
> needed to provide them. The document should lay these out very clearly.
> As the document is currently written, it is difficult to pull out a simple 
> list of
> identified gaps. 

[Bing] A good suggestion. We once had a summary subtitle in previous versions, 
but we deleted it since we thought it might be a little redundancy. 
Now we can add it back, it could be helpful for the readers.

> While addressing that, it would help more to provide some
> sense of the relative importance of addressing each of the gaps identified.

[Bing] We used to divide the gaps into "solvable" and "unsolvable". Some 
important gaps might be unsolvable; while some of the solvable ones might not 
be so important. We'll consider to reflex the two dimensions in the next 
version.

> There are several significant issues with clarity. I will point to the most
> difficult in a section below.
> 
> --
> Minor issues:
> 
> The document currently references
> draft-chown-v6ops-renumber-thinkabout
> several times.
> That document is long expired (2006). It would be better to simply
> restate what is
> important from that document here and reference it only once in the
> acknowlegements
> rather than send the reader off to read it.

[Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap 
analysis. Although the draft is expired, most of the content are still valid. 
draft-chown is a more comprehensive analysis, while the gap draft is focusing 
on gaps in enterprise renumbering. So it might not easy to abstract several 
points as important from draft-chown to this draft. We actually encourage 
people to read it.

> RFC4076 seems to say very similar things to this document. Should it
> have been referenced?

[Bing] RFC4076 is a more specific case of stateless-DHCPv6 [RFC3736], which 
might not be common usage in enterprise. But sure we can consider reference it. 

> Section 5.3 punts discussion of static addresses off to RFC 6866. That
> document was scoped
> only to Enterprise Networks. The scope of this document is larger. Are
> there gaps because
> of that difference in scope that were missed? Would it make sense to
> summarize any gaps
> RFC 6866 identified that are relevant to this document here?

[Bing] This document scope is also for enterprise (it is the 6renum WG scope). 
In fact the RFC6866 is a sub-document of this draft. We considered static 
address problem is an important topic that need a separated document to 
describe. We can consider add a brief summary there.

> Should section 8 belong to some other document? It looks like
> operational renumbering
> advice/considerations, but doesn't seem to be exploring renumbering
> gaps, except for
> the very short section 8.2 which says "we need a better mechanism"
> without much explanation.

[Bing] The multicast and mobility in section 8 were considered as important 
standalone topics that need to be addressed. 
Since multicast is complex, we need more texts to describe the problem than 
describing the gaps directly. But we can make the gaps more clear.

> --
> Text needing clarity (more than nits):

[Bing] We'll also deal with the follo

Re: [mpls] Last Call:

[Luyuan Fang (lufang)]

Hi Russ,

Thanks for your comments, very good points.
Sorry for the delay in replying, I was out of office.

 
The following is my proposed text for replacing the current first
paragraph of section 1.2.

 
Traditional transport technologies include SONET/SDH, TDM, and ATM. There
is a transition away from these transport technologies to new packet
technologies.
In addition to the ever increasing demand for bandwidth, the packet
technologies offer these key advantages:

 
Bandwidth efficiency: Transport technologies supports fixed Bandwidth
only, no packet statistical multiplexing, bandwidth is reserved in
transport
whether used or not by clients. Packet technologies support statistical
multiplexing,
this is the most important motivation for the transition from traditional
transport technologies to packet technologies. The proliferation of new
distributed applications which communicate with servers over the network
in a
bursty fashion has been driving the adoption of packet transport
techniques, since
multiplexing of bursty sources is far more efficient over traditional
circuit-based
TDM technologies.

 
Flexible data rate connections: Traditional transport connection
granularity
is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12,
etc.).
Packet technologies support flexible data rate connections. The support of
finer data rate granularity is important for today¹s wireline and wireless
services and applications.

 
QoS support: While traditional transport, such as TDM transport has
very limited QoS support, packet transport can provide needed QoS
treatment for
IPTV, Voice and Video over IP applications.

 
The root cause for transport moving to packet transport is the shift
of application from TDM to packet. For example, Voice TDM to VoIP; Video to
Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and
Ethernet
VPNs. In addition, network convergence and technology refreshes demand for
common and flexible infrastructure that provides multiple services.

 
Thanks,
Luyuan



-Original Message-
From: Russ Housley 
Date: Saturday, March 23, 2013 3:16 PM
To: "ietf@ietf.org" 
Cc: "m...@ietf.org" 
Subject: Re: [mpls] Last
Call:   

>I wonder if the direction of Section 1.2 can be revised to make it more
>of an engineering document.
>
>It currently says:
>
>   In recent years, the urgency for moving from traditional transport
>   technologies, such as SONET/SDH, TDM, and ATM, to new packet
>   technologies has been rising. This is largely due to the fast growing
>   demand for bandwidth, which has been fueled by the following factors:
>   ...
>
>Please consider an approach that describes the the reasons behind the
>transition from the network operator and network user perspectives:
>
>   Traditional transport technologies include SONET/SDH, TDM, and ATM.
>   There is a transition away from these transport technologies to new
>   packet technologies. In addition to the ever increasing demand for
>   bandwidth, the packet technologies offer these advantages:
>   ...
>
>The fact that IP networks are being used for new applications and that
>the legacy devices are getting old does not motivate the transition to
>packet technologies.  The advantages that packet technologies offer for
>these new applications is the thing that needs to be highlighted here,
>even if it is just a list of bullets.
>
>It seems like the only sentence that addresses this point in Section 1.2
>is: "It streamlines the operation, reduces the overall complexity, and
>improves end-to-end convergence."
>
>Thanks,
>  Russ
>
>On Jan 28, 2013, at 3:01 PM, The IESG wrote:
>
>> The IESG has received a request from the Multiprotocol Label Switching
>>WG
>> (mpls) to consider the following document:
>> - 'MPLS-TP Applicability; Use Cases and Design'
>>   as Informational RFC
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2013-02-11. Exceptionally, comments may
>>be
>> sent to i...@ietf.org instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>> 
>> Abstract
>> 
>>   This document provides applicability, use case studies and network
>>   design considerations for the Multiprotocol Label Switching Transport
>>   Profile (MPLS-TP). The use cases include Metro Ethernet access and
>>   aggregation transport, Mobile backhaul, and packet optical transport.
>> 
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/
>> 
>> IESG discussion can be tracked via
>> 
>>http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/b
>>allot/
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>
>___
>mpls mailing list
>m...@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls



default[4].xml
Description: default[4].xml

Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

[Burger Eric]

Fine with me.

On Apr 1, 2013, at 5:41 PM, Robert Sparks  wrote:

> On 3/28/13 1:17 PM, SM wrote:
>> Hi Eric,
>> At 05:13 28-03-2013, Burger Eric wrote:
>>> Rather than guessing all of the bad things that could happen, I would offer 
>>> it would be better to say what we mean, like:
>>>The IMAP interface MUST NOT provide any IMAP facilities that modify 
>>> the underlying message and message metadata, such as mailbox, flags, 
>>> marking for deletion, etc. If the client is authenticated and authorized, 
>>> the IMAP interface MUST provide per-user marking of the underlying message 
>>> as read or flagged.
>> 
>> The IMAP interface is a front-end to the read-only mailboxes (archive).  
>> It's easier to do what is mentioned above.
> I'm taking more or less that approach in my working copy (I'll be posting -06 
> soon).
>> 
>>> Something to ponder:
>>> I use the IMAP interface once, mark a bunch of things as read, and then 
>>> decide never to use the IMAP interface ever again. How long does the server 
>>> need to keep my (per-user) marking metadata? E.g., besides CPU and I/O 
>>> issues, there is a potentially unbounded storage problem as well. It is 
>>> unbounded because in IMAP I can assign any kind of label (marking) to a 
>>> message, even ones I make up.
>>> 
>>> One thought for an approach to a solution:
>>> 1. per-user markings expire after X time units (six months?)
>>> 2. per-user markings may take up at most X storage units (512KB?)
>> 
>> I would go for both.
> Instead, I propose that we make it possible to notice an abuser and turn off 
> access (this is what -06 will contain).
> 
> I don't believe we could come to a consensus on an automatic expiry of state 
> - there are use cases I can think of where any short
> expiration (like 6-months) would be infuriating.
> 
> If keeping this state for normal use turns out to be too expensive for us, 
> then we will have learned something, and can start talking about future IMAP 
> work in general to help systems mitigate that expense.
>> 
>>> Per-user metadata can be incredibly useful - I might label things by 
>>> project, work group, draft, mumble, or foo. I would not want to limit the 
>>> labels to red or green. However, we need some predictable limit as well.
>> 
>> Yes.
>> 
>> Regards,
>> -sm
> 

Re: [nfsv4] Last Call: (Network File System (NFS) Version 4 Protocol) to Proposed Standard

[Benjamin Kaduk]

I have not yet completed a full review of this (320-page) document, and I 
worry that I may not finish before the deadline, so I am bringing this 
concern to your attention now.


Section 3.2.1.1 of this document ("Kerberos V5 as a security triple") 
seems to indicate that it is mandatory for a conformant NFSv4 
implementation to implement the Kerberos V5 GSS-API mechanism and a few 
"security triples" (mechanism,quality of protection,service).  All of the 
mandatory-to-implement security triples use the DES-MAC-MD5 algorithm. 
The draft goes on to indicate that clients should engage in security 
negotiation (section 3.3) to determine what security to use for bulk 
operation, and that since kerberos-v5 under RPCSEC_GSS is mandatory, the 
negotiation will be performed using that security provider.  The actual 
mechanism resulting from the negotiation may be different (or may be the 
same), but this single-DES mechanism seems to be required to be used to 
protect the negotiation step.


Given that the kerberos working group has published RFC 6649 (Deprecate 
DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos) 
and single-DES is known to be critically vulnerable to brute-force 
attacks, I have grave concern about the IETF publishing new standards 
documents that mandate the implementation of single-DES and do not specify 
strong cryptographic algorithms.  I feel that to do so would be misleading 
implementors into believing that single-DES is sufficient and other 
mechanisms need not be implemented, when in reality this is not true.


Sincerely,

Ben Kaduk
MIT Kerberos Consortium

Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05

[Richard Barnes]

Thanks for following up, and for the re-send.  Just to be clear, I do not
mean these as blocking points.

On the former point, I might just suggest a minor edit to the introduction:
OLD: "This document specifies the options for determination and selection
of next-hop Ethernet MAC addressing under these circumstances."
NEW: "This document specifies the options for determination and selection
of next-hop Ethernet MAC addressing when MPLS-TP is used in a "pure
Ethernet" manner, without any IP forwarding capability."

On the latter point, I can understand the desire to make the simple case
simple, and the text at the end of Section 2 sends a clear warning. It does
seems like GAP would also allow autoconfiguration without further NMS
interaction.  (Unless the NMS is configuring per-Ethernet-address policies,
e.g., "forward packets with this label to 00:11:22:33:44:55". Is that the
case?)




On Tue, Apr 2, 2013 at 9:10 AM, Stewart Bryant  wrote:

>  Resending due to Richards change of address.
>
> Stewart
>
>
> On 11/02/2013 23:45, Richard Barnes wrote:
>
> I have been selected as the General Area Review Team (Gen-ART) reviewer for 
> this draft (for background on Gen-ART, 
> pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please wait for direction from your document shepherd or AD before posting a 
> new version of the draft.
>
> Document: draft-ietf-mpls-tp-ethernet-
> addressing-05
> Reviewer: Richard Barnes
> Review Date: 2013-02-11
> IETF LC End Date: 2013-02-18
> IESG Telechat date: TBD
>
> Summary:  Ready, with a couple of minor questions / clarifications.
>
> Comment:
>
> The document is mostly very clearly written.  (Thanks!)  It would have helped 
> me understand if it could have been clarified up front that the mechanism in 
> this document is intended for "pure Ethernet" MPLS-TP (without assumptions 
> about layer 3+).  The current introduction says as much, but in a negative 
> way, in terms of ARP or ND not being available.
>
> I have some minor unease about the distinction that this document makes 
> between point-to-point and multipoint links.  The document correctly notes 
> that a point-to-point link might become multipoint without either end being 
> aware.  I would have thought this would argue for using GAP in all cases, but 
> instead the document carries on with addressing the point-to-point case 
> separately..
>
>
>  Richard
>
> It is always difficult when writing a simple draft dealing with a small
> component of a larger technology to know how much tutorial to include,
> but I believe the point about operation in the absence IP would be well
> known
> to anyone implementing this. In particular we assume that anyone
> implementing the draft would have read the required references called
> up in the first paragraph of the Introduction:
>
>
> " The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol
> functions that meet the requirements [RFC5654] for the application of
> MPLS to the construction and operation of packet-switched transport
> networks. The MPLS-TP data plane consists of those MPLS-TP functions
> concerned with the encapsulation and forwarding of MPLS-TP packets
> and is described in [RFC5960]."
>
> RFC5654 says:
>
> "   36  It MUST be possible to operate and configure the MPLS-TP data
>plane without any IP forwarding capability in the MPLS-TP data
>plane.  That is, the data plane only operates on the MPLS label."
> Thus I think that the text is complete as it stands and requires no
> further clarification for anyone that needs to consider the technology
> it describes.
>
>
> With regard to your second point, the issue that we are have, is that
> there are a number of deployment scenarios where the operator knows
> that the link is Pt-Pt, and there is a reluctance by that community to
> use anything other than NMS configuration. That has lead them
> to use Ethernet broadcast addressing which allows the crafts to
> change h/w without the need for reconfiguration by the NMS.
> Against that background moving them onto the use of a Ethernet m/c
> address is a step forward. To require using the GAP to that
> community would illustrate that the IETF is out of touch with
> their needs and methods of network operation.
>
> Hopefully this additional background, which I believe is well
> known to the MPLS-TP community to which this draft is directed,
> satisfies your concern on the latter point.
>
> - Stewart
>
>
>
> --
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>

Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

[Ted Lemon]

On Apr 2, 2013, at 6:41 AM, l.w...@surrey.ac.uk wrote:
> Kids! Remember, if we're not bright enough to do physics, we can always do 
> engineering, the slow younger brother of physics!

Is your point that if we do an engineering solution, that will slow things down 
enough that we won't have packet ordering problems?

Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05

[Stewart Bryant]

Resending due to Richards change of address.

Stewart

On 11/02/2013 23:45, Richard Barnes wrote:

I have been selected as the General Area Review Team (Gen-ART) reviewer for 
this draft (for background on Gen-ART, 
pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd or AD before posting a 
new version of the draft.

Document: draft-ietf-mpls-tp-ethernet-addressing-05
Reviewer: Richard Barnes
Review Date: 2013-02-11
IETF LC End Date: 2013-02-18
IESG Telechat date: TBD

Summary:  Ready, with a couple of minor questions / clarifications.

Comment:

The document is mostly very clearly written.  (Thanks!)  It would have helped me 
understand if it could have been clarified up front that the mechanism in this document 
is intended for "pure Ethernet" MPLS-TP (without assumptions about layer 3+).  
The current introduction says as much, but in a negative way, in terms of ARP or ND not 
being available.

I have some minor unease about the distinction that this document makes between 
point-to-point and multipoint links.  The document correctly notes that a 
point-to-point link might become multipoint without either end being aware.  I 
would have thought this would argue for using GAP in all cases, but instead the 
document carries on with addressing the point-to-point case separately..


Richard

It is always difficult when writing a simple draft dealing with a small
component of a larger technology to know how much tutorial to include,
but I believe the point about operation in the absence IP would be well 
known

to anyone implementing this. In particular we assume that anyone
implementing the draft would have read the required references called
up in the first paragraph of the Introduction:


" The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol
functions that meet the requirements [RFC5654] for the application of
MPLS to the construction and operation of packet-switched transport
networks. The MPLS-TP data plane consists of those MPLS-TP functions
concerned with the encapsulation and forwarding of MPLS-TP packets
and is described in [RFC5960]."

RFC5654 says:

"   36  It MUST be possible to operate and configure the MPLS-TP data
   plane without any IP forwarding capability in the MPLS-TP data
   plane.  That is, the data plane only operates on the MPLS label."
Thus I think that the text is complete as it stands and requires no
further clarification for anyone that needs to consider the technology
it describes.


With regard to your second point, the issue that we are have, is that
there are a number of deployment scenarios where the operator knows
that the link is Pt-Pt, and there is a reluctance by that community to
use anything other than NMS configuration. That has lead them
to use Ethernet broadcast addressing which allows the crafts to
change h/w without the need for reconfiguration by the NMS.
Against that background moving them onto the use of a Ethernet m/c
address is a step forward. To require using the GAP to that
community would illustrate that the IETF is out of touch with
their needs and methods of network operation.

Hopefully this additional background, which I believe is well
known to the MPLS-TP community to which this draft is directed,
satisfies your concern on the latter point.

- Stewart



--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

RE: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication

[l.wood]

Kids! Remember, if we're not bright enough to do physics, we can always do 
engineering, the slow younger brother of physics! But if engineering is too 
difficult, there's always computer science, where terms like "bandwidth" mean 
what we want them to mean. And if even that's too hard, there's always the 
arts-and-crafts knitted-my-own-shawl-or-at-least-drew-an-okay-pattern-for-it 
trade of 'Internet Engineering', and writing RFCs.

And we can achieve that RFC goal easily by getting in the back door with an 
April 1 RFC! Every April 1 there's a reminder and inspiration to us all!

Lloyd Wood
http://sat-net.com/L.Wood/

Time's arrow is written >

Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Brian E Carpenter]

Just picking a couple of points for further comment:

On 02/04/2013 08:46, Liubing (Leo) wrote:
> Hi, Robert
...

>> -Original Message-
>> From: Robert Sparks [mailto:rjspa...@nostrum.com]

...
>> The document currently references
>> draft-chown-v6ops-renumber-thinkabout
>> several times.
>> That document is long expired (2006). It would be better to simply
>> restate what is
>> important from that document here and reference it only once in the
>> acknowlegements
>> rather than send the reader off to read it.
> 
> [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the 
> gap analysis. Although the draft is expired, most of the content are still 
> valid. 
> draft-chown is a more comprehensive analysis, while the gap draft is focusing 
> on gaps in enterprise renumbering. So it might not easy to abstract several 
> points as important from draft-chown to this draft. We actually encourage 
> people to read it.

Robert is right, though, sending people to a long-expired draft is a bad idea.
Of course we have to acknowledge it, but maybe we should pull some of its text
into an Appendix.

Tim Chown, any opinion?

>> RFC4076 seems to say very similar things to this document. Should it
>> have been referenced?
> 
> [Bing] RFC4076 is a more specific case of stateless-DHCPv6 [RFC3736], which 
> might not be common usage in enterprise. But sure we can consider reference 
> it. 

Yes, and check if it identifies any gaps that we should mention.

Bing: we should also add a reference to RFC 4085 "Embedding Globally-Routable
Internet Addresses Considered Harmful" which I missed for RFC 6866.

>> Section 5.3 punts discussion of static addresses off to RFC 6866. That
>> document was scoped
>> only to Enterprise Networks. The scope of this document is larger. 

As Bing said, the *intended* scope is enterprise networks. We should
add that in the Abstract and Introduction. Indeed, many of the points
are more general.

Thanks again Robert!

   Brian

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

[Brian E Carpenter]

Fernando,

Rather than repeating myself, I'll suggest a change to the Introduction
that would (IMHO) improve the message:

OLD:

1.  Introduction

   Most general-purpose operating systems implement and enable native
   IPv6 [RFC2460] support and a number of transition/co-existence
   technologies by default.  For cases in which the corresponding
   devices are deployed on networks that are assumed to be IPv4-only,

NEW:

1.  Introduction

   Most general-purpose operating systems implement and enable native
   IPv6 [RFC2460] support and a number of transition/co-existence
   technologies by default [RFC6434]. Support of IPv6 by all nodes is
   intended to become best current practice [RFC6540]. As a result,
   networks will need to plan for and deploy IPv6 and its security
   mechanisms. Some enterprise networks might, however, choose to delay
   active use of IPv6. For networks that are assumed to be IPv4-only,

It would be nice to refer to draft-ietf-v6ops-enterprise-incremental-ipv6
but I think that is too far from RFC publication to be very useful.

Regards
   Brian

On 01/04/2013 14:04, Fernando Gont wrote:
> Brian,
> 
> On 03/29/2013 10:38 AM, Brian E Carpenter wrote:
>> 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.
> 
> That has been my intent, and I sent a note before publishing one of the
> latest revs to double-check that (not sure if I missed your respond, or
> you didn't respond).
> 
> 
>> 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.
> 
> Sites that implement any kind of security policy employ a "default deny
> policy" (for the simple reason that it's safer to open holes than
> explicitly close them). The bottom-line is that if your site enforces
> any kind of security policy, you should make an explicit decision
> regarding what you do with v6, rather than being unaware that it's there
> in your network.
> 
> 
> 
>> 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).
> 
> There's an operational gap here: in many cases, operators have no tools
> to enforce security policies on such tunneled traffic.
> 
> Besides, when thinking about v6, enterprise networks and the like should
> be doing native IPv6 (in which case v6 security controls would be
> enforced throughout the network), rather than having each node go their
> own way.
> 
> 
>> 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.
> 
> In which case you'd be "enforcing IPv6 security controls", which is
> entirely in-line ith what this document is saying.
> 
> 
>> We shouldn't imply that not having an IPv6 plan and blocking all IPv6
>> by default is a sound strategy.
> 
> It's not, and I don't think we're implying that. However, I'd note that
> some people are in the position of blocking traffic, or not doing
> anything about it. Check for IPv6 support in different security
> products, and you might get depressed.
> 
> Cheers,