Re: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Informational RFC

[Sam Hartman]

Glen, I have to agree with Dorothy's comment.  This method should
provide for channel binding support.  I find your unsubstantiated
assertion that doing so wouldbe be absurd uncompelling.

You claim that channel bindings are poorly defined.  I believe that
draft-ietf-emu-chbind brings us most if not all of the way there for
some important use cases.  However if you take a look at that draft,
you'll find that it's a lot better defined for the case where an EAP
method will transport the channel binding than for the case where a
secure association protocol is used.

In particular:

1) The secure association protocol by its nature happens after the
access-accept.  I've already started a session--told the peer to go
ahead with things before channel binding can be confirmed.  It's not
clear in existing secure association protocols where the EAP server gets
to interact with the peer again in order to tell it that channel binding
verification has failed.
So, it is unclear that the primary purpose of channel binding can be
performed in this case.

2) The document does not define sufficient messaging to community with
an AAA server to perform channel binding in a secure association
protocol.

So, basically, I think for channel binding to work  it needs to be
available in the method.

Moreover, whether channel binding is critical in a given deployment is
not actually dependent on whether the methods used in that deployment.
It's dependent on whether a deployment has multiple situations where a
peer could be significantly disadvantaged by authenticating to the wrong
NAS.  So, I cannot see good criteria for deciding when to add channel
binding and when not to add channel binding to new proposed methods.

Certainly, part of this is that I'm working on an EAP deployment where
channel binding is absolutely critical to the security of the
environment.  Especially since I don't see how to actually make it work
with a secure association protocol, I'm strongly in favor of a
requirement to support channel binding in new methods.

--Sam
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only A Password) to Informational RFC

[Glen Zorn]

Dorothy Stanley [mailto:dstan...@arubanetworks.com] writes:


I am submitting one comment on draft-harkins-emu-eap-pwd :

 

(1)   Channel bindings are becoming increasingly necessary for new and
evolving uses of EAP. 

This point is certainly debatable, if for no other reason that the concept
of "EAP channel bindings" seems not to be well-understood, but in any case.

This EAP-PWD protocol should provide for them.

.the idea that individual EAP methods (each and every one) should be forced
to provide support for this rather amorphous capability (of questionable
utility) is absurd.  

Dorothy Stanley

 



Dorothy Stanley

Aruba Networks

dstan...@arubanetworks.com

630-363-1389

 

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

Review of draft-ietf-l3vpn-mvpn-considerations

[Bernard Aboba]

I reviewed the document draft-ietf-l3vpn-mvpn-considerations in general

and for its operational impact.

 

Operations directorate reviews are solicited primarily to help the area

directors improve their efficiency, particularly when preparing for IESG

telechats, and allowing them to focus on documents requiring their attention

and spend less time on the trouble-free ones.

 

Improving the documents is important, but clearly a secondary purpose.

A third purpose is to broaden the OpsDir reviewers' exposure to work going

on in other parts of the IETF.

 

Reviews from OpsDir members do not in and of themselves cause the IESG to

raise issue with a document. The reviews may, however, convince individual

IESG members to raise concern over a particular document requiring further

discussion. The reviews, particularly those conducted in last call and

earlier, may also help the document editors improve their documents.

 

--

 

Review Summary: 

Intended status:  Doesn't say 

 

   More that one set of mechanisms to support multicast in a layer 3

   BGP/MPLS VPN has been defined.  These are presented in the documents

   that define them as optional building blocks.

 

   To enable interoperability between implementations, this document

   defines a subset of features that is considered mandatory for a

   multicast BGP/MPLS VPN implementation.  This will help implementers

   and deployers understand which L3VPN multicast requirements are best

   satisfied by each option.

 

Is the document readable?

 

   Yes. 

 

Does it contain nits?

 

   While there were no errors, idnits did spit out quite a few warnings:

 

idnits 2.12.01 

 

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt:

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(366): Found possible IPv4
address '3.4.1.1' in position 8; this doesn't match the suggested
documentation address ranges specified in RFC 3330 (or successor): blocks
192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
(TEST-NET-3); or the suggested 233.252.0.0/24 example multicast address
range.

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(369): Found possible IPv4
address '3.4.1.2' in position 8; this doesn't match the suggested
documentation address ranges specified in RFC 3330 (or successor): blocks
192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
(TEST-NET-3); or the suggested 233.252.0.0/24 example multicast address
range.

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(372): Found possible IPv4
address '3.4.1.3' in position 8; this doesn't match the suggested
documentation address ranges specified in RFC 3330 (or successor): blocks
192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24
(TEST-NET-3); or the suggested 233.252.0.0/24 example multicast address
range.

tmp/draft-ietf-l3vpn-mvpn-considerations-06.txt(531): Line has weird
spacing: '...   or   the us...'

 

 

  Checking boilerplate required by RFC 5378 and the IETF Trust (see

  http://trustee.ietf.org/license-info):

 


 

  == You're using the IETF Trust Provisions' Section 6.b License Notice from

 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See

 http://trustee.ietf.org/license-info/)

 

 

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:

 


 

  == No 'Intended status' indicated for this document; assuming Proposed

 Standard

 

 

  Checking nits according to http://www.ietf.org/id-info/checklist :

 


 

  == There are 3 instances of lines with non-RFC3330-compliant IPv4
addresses

 in the document.  If these are example addresses, they should be
changed.

 

 

  Miscellaneous warnings:

 


 

 No issues found here.

 

  Checking references for intended status: Proposed Standard

 


 

 (See RFCs 3967 and 4897 for information about using normative
references

 to lower-maturity documents in RFCs)

 

  == Missing Reference: 'RFC4364' is mentioned on line 747, but not

 defined

 'Options A, B and C (as described in section 10 of [RFC4364]) are...'

 

  == Outdated reference: A later version (-10) exists of

 draft-ietf-l3vpn-2547bis-mcast-09

 

  == Outdated reference: A later version (-13) exists of

 draft-rosen-vpn-mcast-12

 

  == Outdated reference: A later version (-10) exists of

 draft-ietf-pim-sm-linklocal-08

 

 

 Summary: 0 errors (**), 7 warnings (==), 0 comments (--).

 

 

Is the document class appropriate?

 

   No class is stated, so I can't tell.   

 

Is the problem well stated?

 

   Yes. 

 

Is the problem really

Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam

[Basil Dolmatov]

+1


John C Klensin пишет:

+1


  

Well, OK.  Let me rephrase my question: why do you believe
that removing the IETF's MX record will

a) decrease the amount of spam it receives?

b) not damage its legitimate mail flow?

Based on my experience and that of other people, neither is
true.

R's,
John




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