Suresh Krishnan | 17 Dec 06:02 2014
Picon

Gen-ART Telechat review of draft-josefsson-pkix-textual-09.txt

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

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

Document: draft-josefsson-pkix-textual-09.txt
Reviewer: Suresh Krishnan
Review Date: 2014/12/16
IESG Telechat date: 2014/12/18

Summary: This draft is ready for publication as a Proposed Standard.

Thanks
Suresh
Suresh Krishnan | 17 Dec 05:14 2014
Picon

Gen-ART Telechat review of draft-ietf-eman-battery-mib-15

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

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

Document: draft-ietf-eman-battery-mib-15
Reviewer: Suresh Krishnan
Review Date: 2014/12/16
IESG Telechat date: 2014/12/18

Summary: This draft is ready for publication as a Proposed Standard.

Thanks
Suresh
Romascanu, Dan (Dan | 16 Dec 12:45 2014

Gen-ART 2nd LC review of draft-ietf-softwire-map-t-08

I am the assigned Gen-ART reviewer for this draft. For background on

Gen-ART, please see the FAQ at

 

<https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=AAICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=wU47cwzdbQA3EthgiqiHsK8wRMdaCD1eucz7eZT_jp4&s=9eC4mYiWqVGeaX_6SSW4A5vbej46w2gZDsZtVb0JKmI&e= >.

 

Please resolve these comments along with any other Last Call comments

you may receive.

 

Document:  draft-ietf-softwire-map-t-08

Reviewer: Dan Romascanu

Review Date: 12/16/14

IETF LC End Date: 12/29/14

IESG Telechat date: not yet

 

Summary: Ready

 

The last pending issue from my initial review was resolved by changing the Intended Status of the document from Experimental to Standards Track

 

Major issues:

 

Minor issues:

 

Nits/editorial comments:

 

 

 

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Russ Housley | 16 Dec 01:02 2014

Gen-ART review of draft-ietf-i2rs-architecture-07

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-i2rs-architecture-07
Reviewer: Russ Housley
Review Date: 2014-12-15
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready.

Major Concerns:

The different between an identity and a role is not clear to me.
Does each identity have exactly one role?  It would help for this to
be covered in section 2, and it may need to be expanded upon in
section 4.

Section 4.2 talks about "groups or roles."  Groups needs to be defined,
even if it is just a list of identities.

Section 6.4 include a sentence that begins, "When a full implementation
is not mandatory, an I2RS Service should ..."  What determines if an
implementation must be "full"?  I think you can make this point without
having to delve into this question.  I suggest: "When a implementation
does offer all of the capabilities specified for an I2RS Service, the
implementation should include a capability model so that peers can
determine which parts of the service are supported."

Section 7.4 says: "Each I2RS Client will have a unique identity; it can
also have secondary identities to be used for troubleshooting."  The
definition in in section 2 offer a proxy-related reason for secondary
identities.

Perhaps all of the discussion of identities can be placed in one
section.  Right now it is split into sections 4 and 7.4.

Minor Concerns:

The document seems to use "confidentiality" and "privacy" to mean the
same thing.  They are different.  See RFC 2828 for definitions.  I 
think that this document should use confidentiality throughout.

The last paragraph in section 1.2 says that the "detection and avoidance
of such interactions is outside the scope of the I2RS work," and that
seems fine, except for one point.  I assume that when there are two
overlapping write operations, one of them will get an error.  The previous
paragraph says that "errors should produce predictable behaviors."  So,
the write operation that fails needs to get an error that will allow the
application to take appropriate action.

In section 4.1, is the reference to "accounting" also a call for audit
trail?  If so, please be explicit.  The need for audit log comes up
later in section 6.2.

Section 7.1 begins: "As agreed by the I2RS working group, this I2RS
architecture assumes ..."  I am sure this was important at one time to
say this, but it seems odd in the final RFC.  I suggest: "The I2RS
architecture assumes ..."

Other Comments:

In the abstract, please spell out I2RS.

Several places starting in the Abstract: s/internet/Internet/

In section 1, it says: "... for registering for and requesting ...";
it should say: "... for registering and for requesting ...".

In section 1, is says: "... in domain other than routing, ...".
s/domain/domains/

Typo: s/E.g./e.g./
Black, David | 16 Dec 00:25 2014

Gen-ART and OPS-Dir review of draft-ietf-httpauth-hoba-07

This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both follows ...

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at:

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

Document: draft-ietf-httpauth-hoba-07
Reviewer: David Black
Review Date: Dec XX, 2014
IETF LC End Date: Dec 24, 2014

Summary: This draft is on the right track, but has open issues
 		described in the review.

This draft specifies a signature-based authentication mechanism for HTTP
that is based on asymmetric (public-private) key pairs without using
certificates.  A different key pair is used by each user for each for
each host ("web-origin", see [RFC6454]), and each signature is based
on a server-generated challenge.

The draft is generally well-written and clear on the authentication
mechanics, but has weaknesses in specifying the environment that
surrounds use of this mechanism.  Some of these issues are basic things
that anyone working on web technology or applied crypto "just knows",
but even the obvious needs to be stated when it's integral to security.

-- Major issues: --

[1] Challenge size and predictability

In the ABNF:

   challenge = 1*base64urlchars

I did not see any other discussion of minimum length of challenge
or amount of entropy in the challenge.  For the latter, do the challenges
need to be unpredictable?  I would think so.

I think a requirement on minimum challenge size and a recommendation on
minimum amount of entropy would be good ideas.

[2] Challenge verification and reuse

This sentence on p.6 strikes me as subtly dangerous:

   The challenge however is sent over
   the network so as to make it simpler for a server to be stateless.
   (One form of stateless challenge might be a ciphertext that the
   server decrypts and checks, but that is an implementation detail.)

The draft elsewhere asserts or assumes that challenge reuse can be
prevented by the server or be time-bounded by max-age, and relies on
those reuse limits for security properties, e.g., as in this sentence
near the end of Section 6.1:

   Note that replay of registration (and other HOBA) messages is quite
   possible.  That however can be counteracted if challenge freshness is
   ensured.

The sentence quoted from p.6 appears to allow (or even encourage)
stateless servers to implement rather weak checks on not only challenge
reuse, but also challenge validity (e.g., what if the challenge validity
test were "challenge mod 1024 == 7" ?).

Allowing such weak checks could enable an attacker to choose or influence
the choice of challenge values, which could be useful (e.g., for
differential cryptanalysis attack on the hash function), as the
attacker (client) already controls the nonce.

As part of this, the server needs to check whether a challenge presented
on one connection or session has been reused on another.  I think the
following sentence in section 3 is intended to prevent this, but it's
weakened by the "stateless" language above:

      The challenge MUST be
      unique for every HTTP 401 response in order to prevent replay
      attacks from passive observers.

Explicit server checks for challenge reuse ought to be REQUIRED, and
the above use of "stateless" needs to be qualified.

[3] Web origin checks

I did not see text mandating that TLS (server certificate), HTTP (accessed
URL) and HOBA (signature input) use the same web origin, and stating that
the server has to check/enforce this.  Did I miss something?

I realize that this is an obvious requirement, but it does need to be
stated.

[4] TLS requirement level

TLS is only a "SHOULD" requirement for HOBA, not a "MUST" requirement -
first paragraph in Section 8.1 (Privacy Considerations).

If TLS is not a "MUST" requirement, at least a discussion of man-in-the-
middle (MITM) attacks seems to be in order.  There's no need for an extensive
discussion of all of the security properties of TLS, but MITM attacks are
definitely worth a mention, and that could be complemented by a pointer to
suitable HTTP/TLS security considerations text elsewhere.

[5] Section 5.3 - unrecognized key

Paragraphs 4 and 5 in this section don't seem to belong here, and appear to
be written in a somewhat loose fashion, particularly around user verification.
A server that does what is suggested here could have significant security
weaknesses.

I strongly recommend replacing those two paragraphs with a short sentence that
says:
	- if a kid is unrecognized or the server otherwise determines
		that the CPK is not to be used for this HTTP authentication,
	- then the Registration (see 6.1) and/or Associating Additional Keys to
		an Exiting Account (see 6.2) processes MAY be used instead of
		treating this situation as an authentication failure.

and moving all discussion of user verification into Sections 6.1 and 6.2.

-- Minor issues: --

[A] ABNF encoding of alg

In section 2, I see:

   alg = 1*2DIGIT

   o  alg: specifies the signature algorithm being used encoded as an
      ASCII character as defined in Section 9.3.

Section 9.3 specifies a single digit.  How does that become 1*2DIGIT ?
I suggest: "as an ASCII character" -> "as one or two ASCII digits based
on the IANA registry established by Section 9.3"

This may seem like a nit, but any imprecision in signature algorithm
input can lead to interoperability problems.

[B] Section 5.3 - CPK vs. kid

   In the authentication phase, the server extracts the CPK from the
   signing phase and decides if it recognizes the CPK.  If the server
   recognizes the CPK, the server may finish the client authentication
   process.

That seems wrong.  IIUC, the HOBA client sends:

   HOBA-RES = kid "." challenge "." nonce "." sig

If so, I don't understand how the server extracts a CPK from that.

I suspect that what was intended is that the server extracts a key identifier
(kid) and then determines a) whether it knows a CPK for that kid and b) whether
it allows use of that kid/CPK for this authentication.  At least a) seems to
be indicated by this text in Section 3:

   The server MUST check the cryptographic correctness of the signature
   based on a public key it knows for the kid in the signatures,

[C] RSA signature algorithm

Section 7 says:

   RSA is defined in
   Section 8.2 of [RFC3447], and SHA-1 and SHA-256 are defined in [SHS].

Section 8.2 of RFC 3447 specifies RSASSA-PKCS1-v1_5.  At a minimum, that
algorithm name should be stated here (which is a nit).  The minor issue is
whether that is the signature algorithm that's wanted, on which I'll defer
to the crypto experts on that (e.g., I seem to recall a negative saag
comment on PKCS 1.5 mechanisms in the past couple of months).

[D] Javascript local storage.

The first paragraph of Section 8.2 on this topic concludes with:

   It's not clear that we
   introduce unique threats from which clear text passwords don't
   already suffer.

That's at odds with the use of "all" in this sentence in the abstract:

   HOBA is an
   alternative to HTTP authentication schemes that require passwords and
   therefore avoids all problems related to passwords, such as leakage
   of server-side password databases.

One of those two paragraphs needs some editing.

-- Nits/editorial comments: --

This is buried near the end of section 6.1

   Note that replay of registration (and other HOBA) messages is quite
   possible.  That however can be counteracted if challenge freshness is
   ensured.

That's not a good place for these two sentences.  HOBA registration
messages don't contain a challenge, and the general discussion of
replay attacks belongs under Security Considerations, not Registration.

In Section 9.4 and 9.5, I see the following proposed as part of IANA
registry contents:

	an unformatted string, at the user's/UA's whim

I get the point, but it's still not appropriate for an IANA registry
- remove ", at the user's/UA's whim".

Appendix A appears  to assume that human-memorable passwords are stored in
the clear in server databases.  It should also briefly discuss the use
of one-way functions, especially computationally intensive ones, to
generate stored password verifiers.  HOBA is still superior by comparison,
as the one-way functions only increase the difficulty of dictionary
attack, whereas dictionary attack on HOBA keys is pointless when
sufficiently large keys are used.

idnits 2.13.01 found the references to W3C's web site (www.w3.org) in
Section 4, e.g.,

389	   One element is required for HOBA-js: localStorage (see http://
390	   www.w3.org/TR/webstorage/) from HTML5 can be used for persistent key
391	   storage.

I think idnits can be ignored, even though the "right way" to fix this is to
move each URL to a reference and cite the reference in Section 4.

OTOH, idnits did not complain about the normative reference to RFC 20 ;-).

--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---

Most of these questions are n/a because this draft describes an extension
to HTTP authentication, and RFC 5706's concerns would apply primarily to
HTTP and HTTP authentication.

A.1.1    Has deployment been discussed?

Yes, section 6 discusses how a user would deploy this for her access to web
servers.

A.1.4.  Have the Requirements on other protocols and functional
       components been discussed?

Yes, the discussion of how this functions within HTTP is sufficient.

Major issues [3] and [4] fall into this category, but in both cases,
I think they're probably text oversights that are easy to fix.

A.2.7 Is security management discussed?  

Not really, but this is an Experimental RFC.  I would expect that the
experimental use of HOBA will yield insight into server key database
structure/management, key lifecycle management (e.g., revocation),
account management techniques/processes, etc.

A.3.  Documentation

I do not expect significant operational impact.

Section 10 notes the existence of two implementations of HOBA-JS and
one implementation of HOBA-http.  That's a good start for an experiment.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------
A. Jean Mahoney | 15 Dec 21:51 2014

A *new* batch of IETF LC reviews - 2014-12-15

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------

Dan Romascanu     2014-12-29   draft-ietf-softwire-map-t-08 *

Suresh Krishnan   2014-12-25   draft-ietf-rtgwg-remote-lfa-08

Tom Taylor        2014-12-26   draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07

Vijay Gurbani     2015-01-09   draft-farrkingel-pce-abno-architecture-13

* 2nd LC

I have made (most of) the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
Elwyn Davies | 15 Dec 09:11 2014
Picon

Re: Gen-art LC review of draft-ietf-mpls-tp-te-mib-09

On 15/12/14 03:08, Sam Aldrin wrote:
Hi Elwyn,

Thanks again.

Comments inline. 
Also attached txt and diff files.

Hi, Sam.

<Snipping all the history>

Thanks for all the work on this and apologies for the lack or understanding around 'sparse'.

I think you are good to go on this version as far as my issues were concerned.

Cheers,
Elwyn
_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Russ Housley | 12 Dec 15:53 2014

Gen-ART review of draft-ietf-i2rs-problem-statement-04

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-i2rs-problem-statement-04
Reviewer: Russ Housley
Review Date: 2014-12-11
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready.

Major Concerns:

Section 5 says, "Data written can be owned by different I2RS clients."
The intended consequences are unclear.  I assume that the data written
by one client cannot be rewritten by another client.  However, I can
imagine some situations where the same data object might be written by
more than one client at different times.  Please add some language to
say whether this situation is within scope or not.

Section 5 includes a requirement for multi-channel.  I would expect
policy to dictate that some requests, especially ones that impact the
whole router, come from a specific source.  This might require that
the request arrive on a particular port or that it be authenticated in
a particular manner.  Can more be said about the policy controls here?

Section 8 seems very thin to me.  There are some lessons from MIBs
documented here: www.ops.ietf.org/mib-security.html.  I think that
some of this extrapolates to this document, but I do not think that
a pointer to those guidelines is the best way forward.

Minor Concerns:

The document talks about the IESG statement issued on 2 March 2014.
Please add a reference, which is probably best done with a URL.

Section 5 says that the ability to manipulate routing controls is
"subject to authentication and authorization."  This is highly desirable.
Can we go a little bit further?  Is it like root on a Unix box, or is
the authorization more granular?  Are there known roles that must be
supported?

Other Comments:

Section 5 says: "Such communications must also have its integrity
protected."  I do not know how to do authentication without also
providing integrity, so this is really implied by the previous
sentence.  That said, I suggest the following wording: "Such
communications must be integrity protected."
Elwyn Davies | 12 Dec 14:25 2014

Fwd: Re: draft-ietf-savi-dhcp-30 posted


-------- Forwarded Message --------
Subject: Re: draft-ietf-savi-dhcp-30 posted
Date: Fri, 5 Dec 2014 00:44:45 +0000
From: Fred Baker (fred) <fred <at> cisco.com>
To: Elwyn Davies <elwynd <at> dial.pipex.com>
CC: Kathleen Moriarty <kathleen.moriarty.ietf <at> gmail.com>, Ted Lemon 
<ted.lemon <at> nominum.com>, draft-ietf-savi-dhcp.all <at> tools.ietf.org 
<draft-ietf-savi-dhcp.all <at> tools.ietf.org>, Ralph Droms (rdroms) 
<rdroms <at> cisco.com>, Barry Leiba <barryleiba <at> computer.org>

Thanks. I’ll talk with my co-authors and see if we can get this sorted out.

On Dec 4, 2014, at 3:58 PM, Elwyn Davies <elwynd <at> dial.pipex.com> wrote:

> Hi, Fred,
>
> This version is a *great* improvement, especially as regards language issues.  There are a few nits that
I'll send in a separate email.
>
> Some points that are not covered by the discussion below:
>
> s4.3.2, bullets (1) and (2):  Although it is now clearer from s4.2.5 why Validating might be a separate
attribute, the configuration guidelines don't suggest that it could be set otherwise than the same as
DHCP-Snooping which looks as if it gets us back to the previous situation that was pointed out in earlier
reviews.  Notes about why one might set Validation False but DHCP-Snooping True should be added here to
complement the previous explanation of Validating..
>
> s4.3.2/s4.3.3/s4.3.4/s8:
> s4.3.2:
>>   The perimeter is also a perimeter for DHCP messages.  The DHCP-Trust
>>   attribute is only TRUE on the inside links of the perimeter.  Only
>>   DHCP server-to-client messages originated within the perimeter are
>>   trusted.
> s4.3.3:
>>   Thus, the DHCP server A cannot be contained within the perimeter
>>   apart from manual configuration of the binding anchor.
>>
>>   Another consideration on the placement is that if the DHCP server/
>>   relay is not inside the perimeter, the SAVI devices may not be able
>>   to set up bindings correctly, because the SAVI devices may not be on
>>   the path between the clients and the server/relay, or the DHCP
>>   messages are encapsulated (e.g., Relay-reply and Relay-forward).
> s4.3.4:
>>   To configure such a perimeter, at minimum the DHCP messages from
>>   upstream networks MUST be ensured to be trustworthy.  Achieving this
>>   is beyond the scope of this document.
> s8:
>>   For attachments with other attributes:
>>
>>   DHCP Server-to-Client messages not from attachments with the DHCP-
>>   Trust attribute or Trust attribute MUST be discarded.
>>
>>   For attachments with no attribute:
>>
>>   DHCP Server-to-Client messages from such attachments MUST be
>>   discarded.
>
> I don't think the combination of these statements achieves consistency.  It seems to say that "yes, you can
have DHCP servers outside the perimeter" but then you can't set the DHCP-Trust attribute on the
attachment, and BTW, we are going to punt on how you would make the connection trustworthy - the bit about
manual configuration of a trust anchor doesn't seem to cover the situation since other DHCP servers
*inside* the perimeter don't use trust anchors and the way s8 is written any DHCP Server-to-Client
messages would get discarded anyway.
>
> This issue harks back to the IPsec text in -28 mentioned below, since I think the idea was that you might have
an IPsec tunnel out to the DHCP server or maybe use IPsec on all DHCP connections.  To partly answer the
question below, there is no point in discussing IPsec in this context until the authors have their heads
round the whole upstream DHCP Server question properly. And if "out of scope" is the answer then the IPsec
question is moot.
>
>
> s6.4.4/s7.9:
>>   Timeout: EVE_ENTRY_EXPIRE
> These aliases are redundant since the event name is used in the state table.
>
> s7.7.1/s7.8/s7.8.3/s7.9:
> I don't understand why the EVE_ENTRY_EXPIRE timeout event is not observed (s7.8.3).  The timeout period
is set in s7.7.1 before transition to the BOUND state. In s7.8.3 nothing is said after EVE_ENTRY_EXPIRE. 
In s7.9 it is clear that once the state gets to BOUND it stays there.  This doesn't seem right.
>
> s11.2: In bullet point (1) it should be clearer that the timer is in addition to the lease/anchor timeout
(well I think it has to be) so that if the client comes back on line as in bullet (3) the lease/anchor timeout
is back in action and presumably runs to the expiry it would have done in the absence of the whole off-link
business.  Reactivating or just having the two running in parallel - in fact it has to be this latter so that
if the lease goes while the node is off-link it will be correctly unbound. - needs to be noted.
>
>
> Some notes on the issues below.
>
> Regards,
> Elwyn
>
> On 04/12/14 02:17, Fred Baker (fred) wrote:
>> We have posted draft-ietf-savi-dhcp-30. In that we think we have
>> address all of Kathleen’s, Ted’s, and Barry’s comments, and most of
>> Elwyn’s. We have a few open issues that will need to be addressed in
>> a -31 version. Depending on the guidance we receive, -30 could go for
>> further wider review, or -31 could do that. We’re waiting for your
>> guidance.
>>
>>
>> One open issue has to do with what looks like an inconsistency in RFC
>> 3315, which is being updated in dhc as we speak and we are in
>> correspondence with Ralph about. This has to do with (Elwin’s
>> comment) the lifetime of a temporary address assigned using DHCP. As
>> we understand 3315 section 10, all IAs carry a lifetime for each
>> address they carry. Section 12 says that the IA_TA carrying a
>> temporary address does not contain a lifetime. Ralph tells us, in
>> private email, that it does. We think that has to be addressed by
>> dhc.
>
> I'll leave that one to Ralph and dhc.
>
>>
>> Another open issue has to do with the terms “upstream” and
>> “downstream” as used by the document. In short, the question is
>> whether the SAVI device can legitimately expect to see all DHCP
>> messages related to a given host; a downstream device/link would see
>> all such, and an upstream device/link would not necessarily see them
>> all. That said, the terminology would appear to suggest that the SAVI
>> domain is at the edge of a network, with no other separate SAVI
>> domains beyond it, which may not be true. We discussed using the
>> terms “protected” and “unprotected”, and would like reviewer advice:
>> would that be an improvement? Are there other terms that might be
>> preferable?
>
> How about "controlled (external)" and "uncontrolled (external)"?  I think there is really a third
category of "internal".
>
>>
>>> RFC 5007 recommends that LEASEQUERY/LEASEQUERY_REPLY messages
>>> should be protected by IPsec...
>>
>> True. For the switch to send such a message to a DHCP server, either
>> the switch must have an IPsec security association with the server,
>> or the server needs to be able to accept a non-IPsec-protected
>> message from the switch. Unless we can trigger the host to initiate
>> the LEASEQUERY, we think this has to be handled operationally. What
>> text would the reviewers recommend?
>
> Have you asked the Security ADs and the dhc WG how bad they would consider it to be if the LEASEQUERY
interaction didn't go over an IPsec channel?  My feeling is that you maybe throwing away quite a bit of the
supposed gains from doing SAVI-DHCP if you don't protect the LEASEQUERY channel, but I am not an expert in
this area.
>
> At the bare minimum the issue needs to be documented, irrespective of what the eventual recommendation or
mandate is..  You can probably get away with manually configured keys since presumably there are not many
boxes involved, but it does mean extra complexity in the SAVI devices.
>>
>> There used to be some discussions on IPSec issues( s11.5 in
>> savi-dhcp-28). They are removed due to comments received. Should they
>> be added in again(after revision) ?
>
> See the previous comments on the external DHCP server issue.
>
>>
>> To Elwyn’s remaining unaddressed comments: we think they require no
>> action.
>>
>>> The definitions in s3 and the descriptions of the need to
>>> distinguish between upstream and downstream links would appear to
>>> rule out the use of SAVI as currently specified in situations where
>>> transit traffic and destination traffic share the same link.
>>> Presumably this rules out quite a few wi-fi networks, for example
>>> IPv6 networks with multiple subnets per link and possibly
>>> situations where there are multiple routers in series.
>>
>> The question is whether DHCP messages go through the switch to the
>> host in question. If we see the DHCP messages, we can create a
>> binding for the host; if we don’t, we can’t. Hence, upstream links
>> (paths to devices we may not see the DHCP messages for) cannot be
>> protected by this model, and are precluded by configuring attributes
>> on the relevant interfaces. We believe that the draft identifies the
>> fact and specifies those links.
>>
>
> I'm going to postpone judgement on this one  until I have slept on it and reread the new version.  It is still
nagging at my brain that there are more complex situations where the scheme falls down.
>
>>> s1: The reference to RFC 2827 (aka BCP38) might better refer to the
>>> more extensive RFC 3704 (BCP 84) - and, in any case, use the BCP
>>> reference rather than the RFC to cover any future update.
>>
>> Speaking as one of the authors of RFC 3704. RFC 2827 (BCP 38)
>> protects a network from spoofed traffic coming from outside of it
>> (usually a customer) by asking whether the source address is
>> reasonable, and drops the message if it is not. RFC 3704 (BCP 84)
>> suggests routing solutions would enable a network to route traffic to
>> an upstream ISP that will not drop it following BCP 38, and describes
>> uRPF filtering, which is a form of routing-based filter that could be
>> used to implement BCP 38. When the switch thinks it is reasonable to
>> accept some given set of IP addresses from the set of hosts attached
>> to a given port, and drops messages with other addresses, it is
>> similar to BCP 38, not BCP 84.
>>
> I'll accept that for the simple cases RFC 2827 is fine.
>
> After I have seen the authors' responses to the external DHCP server issue raised above, I reserve the
right to revive the proposal.
>
>>> Specifying the Data-Snooping state machine as a modification of the
>>> DHCP-Snooping state machine is confusing.
>>
>> In -30 at least, the two FSMs are separate.
>>
> Yes indeed.  Thank goodness!  So this one is done.

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Elwyn Davies | 12 Dec 14:25 2014

Fwd: Re: draft-ietf-savi-dhcp-30 posted


-------- Forwarded Message --------
Subject: Re: draft-ietf-savi-dhcp-30 posted
Date: Fri, 5 Dec 2014 01:19:41 +0000
From: Fred Baker (fred) <fred <at> cisco.com>
To: Elwyn Davies <elwynd <at> dial.pipex.com>
CC: Kathleen Moriarty <kathleen.moriarty.ietf <at> gmail.com>, Ted Lemon 
<ted.lemon <at> nominum.com>, draft-ietf-savi-dhcp.all <at> tools.ietf.org 
<draft-ietf-savi-dhcp.all <at> tools.ietf.org>, Ralph Droms (rdroms) 
<rdroms <at> cisco.com>, Barry Leiba <barryleiba <at> computer.org>

On Dec 4, 2014, at 3:58 PM, Elwyn Davies <elwynd <at> dial.pipex.com> wrote:
>> One open issue has to do with what looks like an inconsistency in RFC
>> 3315, which is being updated in dhc as we speak and we are in
>> correspondence with Ralph about. This has to do with (Elwin’s
>> comment) the lifetime of a temporary address assigned using DHCP. As
>> we understand 3315 section 10, all IAs carry a lifetime for each
>> address they carry. Section 12 says that the IA_TA carrying a
>> temporary address does not contain a lifetime. Ralph tells us, in
>> private email, that it does. We think that has to be addressed by
>> dhc.
>
> I'll leave that one to Ralph and dhc.

For the record, I had a conversation with Ted, Ralph, and the folks 
doing 3315bis. There is in fact a lifetime on a IA_TA; this is described 
in 3315 section 22.6, where there are two lifetimes specific, and a rule 
for determining which lifetime applies. So Temporary Addresses have a 
specified lifetime. They agreed to clarify this in 3315bis.

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Elwyn Davies | 12 Dec 14:25 2014

Fwd: Re: draft-ietf-savi-dhcp-30 posted


-------- Forwarded Message --------
Subject: Re: draft-ietf-savi-dhcp-30 posted
Date: Thu, 4 Dec 2014 14:12:46 +0000
From: Ralph Droms (rdroms) <rdroms <at> cisco.com>
To: Fred Baker (fred) <fred <at> cisco.com>
CC: Elwyn Davies <elwynd <at> dial.pipex.com>, Kathleen Moriarty 
<kathleen.moriarty.ietf <at> gmail.com>, Ted Lemon <ted.lemon <at> nominum.com>, 
draft-ietf-savi-dhcp.all <at> tools.ietf.org 
<draft-ietf-savi-dhcp.all <at> tools.ietf.org>, Barry Leiba 
<barryleiba <at> computer.org>

Responding to the open issue regarding temporary addresses...

On Dec 3, 2014, at 6:17 PM 12/3/14, Fred Baker (fred) <fred <at> cisco.com> 
wrote:

> We have posted draft-ietf-savi-dhcp-30. In that we think we have address all of Kathleen’s, Ted’s,
and Barry’s comments, and most of Elwyn’s. We have a few open issues that will need to be addressed in a
-31 version. Depending on the guidance we receive, -30 could go for further wider review, or -31 could do
that. We’re waiting for your guidance.
>
>
> One open issue has to do with what looks like an inconsistency in RFC 3315, which is being updated in dhc as we
speak and we are in correspondence with Ralph about. This has to do with (Elwin’s comment) the lifetime
of a temporary address assigned using DHCP. As we understand 3315 section 10, all IAs carry a lifetime for
each address they carry. Section 12 says that the IA_TA carrying a temporary address does not contain a
lifetime. Ralph tells us, in private email, that it does. We think that has to be addressed by dhc.

I've sent a message to the document team that is working on RFC3315bis. 
  I don't know if this particular issue has already been identified for 
clarification.

I wrote to the document team:

>
> My recollection is that the intention for IA_TA is that the addresses in an IA_TA have lifetimes, but the
client is not expected to renew the lease on the address.  That recollection is supported, in my opinion, by
this paragraph from 22.5:
>
>   An IA_TA option does not include values for T1 and T2.  A client MAY
>   request that the lifetimes on temporary addresses be extended by
>   including the addresses in a IA_TA option sent in a Renew or Rebind
>   message to a server.  For example, a client would request an
>   extension on the lifetime of a temporary address to allow an
>   application to continue to use an established TCP connection.

I'll let you know what comes back from the document team.  We may end up 
taking the question to the dhc WG as a whole...

- Ralph

> [...]

Gmane